Consumer Device Based Point-Of-Sale

ABSTRACT

Systems and related methods facilitating interactions between a merchant device, a central system and a consumer device are discussed herein. Wallet identifying data may be used to secure messages between the consumer device and the merchant device over a wireless link. For example, the merchant device may include circuitry configured to wirelessly receive the wallet identifying data from a consumer device and to transmit the wallet identifying data to the central system. In response, consumer identifying data associated with the wallet identifying data may be received by the merchant device from the central system. In some embodiments, the consumer identifying data may be associated with a unit of location, such as a dine-in location at a restaurant, to facilitate consumer service.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/794,529, entitled “Consumer Device Based Point-of-sale,” filed Mar.11, 2013, which is incorporated by reference in its entirety herein.

This application incorporates by reference each of the following intheir entirety: U.S. Provisional Patent Application No. 61/715,229,entitled “Peer-to-Peer Payment Processing,” filed Oct. 17, 2012, U.S.Provisional Patent Application No. 61/715,230, entitled “ConsumerPresence Based Deal Offers,” filed Oct. 17, 2012, U.S. ProvisionalPatent Application No. 61/706,664, entitled “Online Ordering for In-ShopService,” filed Sep. 27, 2012, and U.S. patent application Ser. No.13/764,753, entitled “Consumer Device Payment Token Management,” filedFebruary 11, 2013.

FIELD

Embodiments of the invention relate, generally, to facilitatinginteractions between consumer devices and merchant point-of-saledevices.

BACKGROUND

Financial transactions between merchants and consumers typically requirethe consumers to present a form of payment to the merchant. As a result,consumers may be required to keep wallets that include paymentinstruments such as cash, credit cards, debit cards, deal vouchers,coupons, reward tracking cards, checks or the like that may be acceptedby merchants and/or their devices used at the point-of-sale (e.g.,point-of-sale devices, such as cash registers, credit card readers,etc.). These payment instruments, in addition to being inconvenient tocarry and use, also do not provide consumer information to merchantsthat can be leveraged to improve service. In this regard, areas forimproving current systems have been identified. Through applied effort,ingenuity, and innovation, solutions to improve such systems have beenrealized and are described in connection with embodiments of the presentinvention.

BRIEF SUMMARY

Systems, methods, and computer readable program code are provided to, ingeneral, facilitate consumer location-based service at a merchant shop.For example, some embodiments may provide for a merchant device. Themerchant device may include a display configured to present interactivedisplays, communications circuitry configured to facilitatecommunications with a consumer device and a central system, andprocessing circuitry. The processing circuitry may be configured to:wirelessly receive wallet identifying data from the consumer device;transmit the wallet identifying data to the central system; receive,from the central system, consumer identifying data associated with thewallet identifying data; and associate the consumer identifying datawith a unit of location at a merchant shop.

In some embodiments, the processing circuitry of the merchant device maybe configured to: determine location data based on a wirelesscommunication received from the consumer device; and determine the unitof location based on the location data. The wireless communication maybe based on one or more signals using near field communication (NFC),Quick Response (QR) code, radio frequency identification (RFID),triangulation, or received signal strength indication (RSSI).

In some embodiments, the unit of location may be a dine-in location at arestaurant. The dine-in location may be associated with a tableidentifier that identifies, for example, a table at the restaurant. Theprocessing circuitry of the merchant device may be configured todetermine, based on the location data, the table identifier from aplurality of table identifiers.

In some embodiments, the processing circuitry of the merchant device maybe configured to provide a graphical representation a floor plan with atleast some of the consumer identifying data associated with the dine-inlocation within the floor plan. The graphical representation of thefloor plan may be part of a user interface that further includes agraphical layout of a plurality of tables within the restaurant.

In some embodiments, the merchant device may be configured to facilitatepayments. For example, the processing circuitry may be configured to:associate the consumer identifying data with a restaurant tabidentifier; associate menu item data indicating one or more menu itemswith the restaurant tab identifier; determine a payment amount based onthe menu item data; wirelessly send the payment amount to the consumerdevice; wirelessly receive consumer approval data indicating approval ofa payment for at least the payment amount from the consumer device, theconsumer approval data secured with a private key associated with thewallet identifying data; and send secured payment approval data based onthe consumer approval data to the central system.

In some embodiments, the processing circuitry of the merchant device maybe configured to: receive, from the central system, consumer informationassociated with the consumer identifying data; and provide the consumerinformation to the display when the consumer device is in proximity tothe dine-in location. The consumer information may include the dine-inlocation preference data and the merchant device may be configured todetermine the dine-in location at the restaurant based on the dine-inlocation preference data. Additionally and/or alternatively, theconsumer information may include dine-in preference data configured tofacilitate customized dining service, menu item purchase history data,one or more promotional deals redeemable at the restaurant and/orprofile information of a consumer associated with the wallet identifyingdata,.

In some embodiments, the processing circuitry of the merchant device maybe further configured to: receive consumer information entered via aninteractive display presented on the display; and send the consumerinformation to the central system. The consumer information may includeone or more ordered menu items and/or dine-in location preference datawirelessly received from the consumer device and configured tofacilitate a determination of the dine-in location at the restaurant.

Some embodiments may provide for a consumer device. The consumer devicemay include a display configured to present interactive displays,communications circuitry configured to facilitate communications with amerchant device and a central system, and processing circuitry. Theprocessing circuitry may be configured to: receive wallet identifyingdata from the central system, the wallet identifying data associatedwith consumer identifying data that identifies a consumer; wirelesslysend the wallet identifying data to a merchant device; and wirelesslytransmit one or more communications configured to indicate a unit oflocation at a merchant shop.

Some embodiments may provide for a central system. The central systemmay include a networked device that includes communication circuitryconfigured to facilitate communications with a consumer device and amerchant device and processing circuitry. The processing circuitry maybe configured to: send wallet identifying data to the consumer device,the wallet identifying data associated with consumer identifying datathat identifies a consumer; receive the wallet identifying data sent tothe consumer device from the merchant device; and send first consumerinformation associated with the consumer identifying data to themerchant device, the first consumer information configured to facilitateconsumer service at a merchant shop.

In some embodiments, the central system may be further configured to:receive second consumer information from the merchant device, the secondconsumer information determined by the merchant device after sending thewallet identifying data to the processing circuitry of the networkeddevice; and associate the second consumer information with the consumeridentifying data.

Some embodiments may include one or more methods discussed herein. Otherembodiments may include one or more machines, such as an apparatusand/or system, configured to implement the methods and/or otherfunctionality discussed herein. For example, the machine may include oneor more processors and/or other machine components configured toimplement the functionality discussed herein based on instructionsand/or other data stored in memory and/or other non-transitory computerreadable media.

These characteristics as well as additional features, functions, anddetails are described below. Similarly, corresponding and additionalembodiments are also described below.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described some embodiments in general terms, reference willnow be made to the accompanying drawings, which are not necessarilydrawn to scale, and wherein:

FIG. 1 a shows a flow chart of an example method for determining thepresence of a consumer, performed in accordance with some embodiments;

FIG. 1 b shows a flow chart of an example method for facilitating afinancial transaction, performed in accordance with some embodiments;

FIG. 2 a shows a flow chart of an example method for accessing aconsumer payment account, performed in accordance with some embodiments;

FIG. 2 b shows a flow chart of an example method for creating a consumerpayment account, performed in accordance with some embodiments;

FIGS. 3-12 show example graphical user interface displays that may bepresented by various components of systems, in accordance with someembodiments;

FIG. 13 a shows a flow chart of an example data flow for associating aconsumer with a dine-in location, performed in accordance with someembodiments;

FIG. 13 b shows a flow chart of an example method for associating aconsumer with a dine-in location, performed in accordance with someembodiments;

FIG. 14 shows a flow chart of an example method 1400 for facilitatingconsumer and merchant dine-in interactions, performed in accordance withsome embodiments;

FIG. 15 shows a flow chart of an example data flow for facilitatingtransactions between a consumer and an employee, performed in accordancewith some embodiments;

FIGS. 18-26 show example graphical user interface displays that may bepresented by various components of systems, in accordance with someembodiments;

FIG. 27 shows an example system for facilitating interactions betweenemployees and consumers, configured in accordance with some embodiments;and

FIG. 28 shows an example schematic block diagram of circuitry,configured in accordance with some embodiments.

DETAILED DESCRIPTION

Embodiments will be described more fully hereinafter with reference tothe accompanying drawings, in which some, but not all embodimentscontemplated herein are shown. Indeed, various embodiments may beimplemented in many different forms and should not be construed aslimited to the embodiments set forth herein; rather, these embodimentsare provided so that this disclosure will satisfy applicable legalrequirements. Like numbers refer to like elements throughout.

As used herein, the terms “data,” “content,” “information” and similarterms may be used interchangeably to refer to data capable of beingcaptured, transmitted, received, displayed and/or stored in accordancewith various example embodiments. Thus, use of any such terms should notbe taken to limit the spirit and scope of the disclosure. Further, wherea computing device is described herein to receive data from anothercomputing device, it will be appreciated that the data may be receiveddirectly from the another computing device or may be received indirectlyvia one or more intermediary computing devices, such as, for example,one or more servers, relays, routers, network access points, basestations, and/or the like. Similarly, where a computing device isdescribed herein to send data to another computing device, it will beappreciated that the data may be sent directly to the another computingdevice or may be sent indirectly via one or more intermediary computingdevices, such as, for example, one or more servers, relays, routers,network access points, base stations, and/or the like.

Overview

Embodiments discussed herein may be configured to allow a merchantdevice at a merchant's shop to communicate with a consumer devicecarried by a consumer to enhance consumer service. One example of asuitable type of merchant discussed herein is a dine-in restaurant. Assuch, while many of the example embodiments are described herein in thecontext of a dine-in restaurant, they may be readily extended to othertypes of merchants by a person of ordinary skill in the art. Forexample, some embodiments described herein may utilize a dine-inlocation (e.g., a table) at a restaurant but the techniques disclosedherein are also suitable to other units of location, such as a kiosk,aisle, information desk, display, counter, or the like at a retailstore, restaurant, or any other type of merchant shop that servesconsumers.

With reference to a restaurant, the merchant may identify the consumervia the consumer device when the consumer walks into the restaurant.Based on the consumer's preferences, which may be sent by the consumeror a central system (e.g., based on the consumer's identity), theconsumer may be automatically placed into a virtual seating wait list.For example, the consumer may have a party of five people, and may beplaced in line for a suitable dine-in location (e.g., a table for five).

When a suitable dine-in location becomes available, the merchant devicemay associate the consumer with a table. Furthermore, an alert may besent to the consumer device that indicates table availability. While theconsumer is seated, alerts and other information may be displayed on themerchant device to facilitate dine-in service. For example, informationregarding consumer preferences for menu items (e.g., favorite foods,allergies, etc.) may be shown on a merchant device carried by a serveras the server takes orders at the table. As such, the server may usethis information in providing recommendations or customizing orders. Inanother example, the consumer may use the consumer device to requestassistance from a server. An alert may be shown on the merchant deviceresponsive to the request and the server may provide assistanceaccordingly.

The merchant device may also include point-of-sale (POS) functionality.For example, the merchant device may also be configured to assist increating and managing restaurant tabs. As such, the server may entermenu items ordered by the consumer via the merchant device, such as viatouch screen in a graphical user interface. The entered menu items maybe sent to a ticket printer and/or sent to a display device (e.g., in akitchen or bar) for menu item preparation. Furthermore, the merchantdevice may associate the entered menu items with the consumer'srestaurant tab.

Some embodiments discussed herein may be configured to allow a consumerto provide payments to the merchant using the consumer device. Forexample, the consumer may send an indication to the merchant device thatthe meal is completed. To facilitate payment, the merchant device maysend the restaurant tab (e.g., transaction data that includes a paymentamount) to the consumer device. Rather than having to carry physicalpayment instruments, such as credit cards, currency, checks, and/orother items typically stored in a physical wallet, the consumer may makepayments from a consumer payment account simply by carrying and/or usingthe consumer device.

Throughout the dine-in experience, the merchant device may be configuredto collect consumer information that it learns from interactions withthe consumer. As such, the consumer information may be leveraged by themerchant upon a subsequent visit to the restaurant by the consumer.

An advantage that may be realized by some embodiments discussed hereinis that the consumer device can be configured to wirelessly communicatewith the merchant device via a Personal Area Network (PAN) connection(e.g., via Bluetooth) or other unsecure direct connection. As such, theconsumer device does not any an active internet connection (e.g., to thecentral system, merchant device, etc.) at the restaurant to facilitatethe functionality discussed herein.

Some embodiments may provide for the securing of sensitive data (e.g.,payment information or consumer information) to protect consumers andmerchants from unauthorized devices on the PAN network or fraudulenttransactions. For example, the consumer device may share walletidentifying data (or data secured with wallet identifying data), orwallet identifying tokens, with the merchant device via the PANconnection in lieu of unsecured sensitive data. The merchant device maysend wallet identifying data received from the consumer device to thecentral system and receive consumer information from the central systemvia a secure connection. As such, the PAN connection is not used toexchange unsecured consumer information.

In another example, wallet identifying data and/or an associated privatekey may be used to secure or otherwise verify transaction data, forexample, when the consumer is ready to make a payment. The consumerdevice may be configured to use the wallet identifying token and/orassociated private key to sign (e.g., create an electronic signature orthe like) the transaction data to form consumer approval data. Themerchant device may generate secured payment approval data upon receiptof the consumer approval data. As discussed in greater detail herein,this “secured payment approval data” may be reveal little or no usefulinformation to unauthorized devices who might intercept this signal. Themerchant device may then send the secured payment approval data to thecentral system for processing of a financial transaction between theconsumer and merchant.

Some other, but non-exhaustive, advantages that may be realized by someembodiments discussed herein include allowing a merchant to ensure thatthe consumer device user is in fact the real person authenticated to theconsumer device, consumer device location tracking to facilitateservice, allowing payments between two peer devices and/or providingpromotional offerings (e.g., promotional vouchers, sales, discounts,rewards, or the like) to the consumer.

Consumer Presence Detection Overview

FIG. 1 a shows a flow chart of an example method 100 for determining thepresence of a consumer, in accordance with some embodiments. Method 100is meant to show a high level example, while some of the other processesflows and other drawings discussed herein show more detailed examples.While other embodiments may operate differently, the examples discussedherein are largely focused on detecting the consumer's presence based onthe consumer device being in communicable range with the merchantdevice. For example, both the consumer device and the merchant devicemay be running a Bluetooth-compliant protocol, such as Bluetooth v4,and/or be configured to establish/join any other type of PAN.

At 102, a central system may be configured to send wallet identifyingdata to a consumer device. The term “central system” as used hereinrefers to any marketing system, payment processing system, couponprovider system, and/or any other type of promotional system controlledby a merchant, third party and/or any other type of user (e.g., such ashardware provider, software application developer, online retailer,brick-and-mortar retailer, etc.). The central system may be accessiblevia one or more computing devices and may be operable to provide examplepromotion and/or marketing services on behalf of one or more providersthat are offering one or more vouchers that are redeemable for goods,services, experiences and/or the like. The central system may be furtherconfigured to illustrate or otherwise inform one or more consumers ofthe availability of one or more vouchers (e.g., deals) in the form ofone or more offers. In some examples, the central system may also takethe form of a redemption authority or payment processor, it may providerewards indications and/or it may function as an entity within afinancial network. As such, the central system is, in some exampleembodiments, configured to present one or more offers, accept paymentsfor offers from both merchants and consumers, upon acceptance of anoffer, issue vouchers, indicate whether a voucher is valid for thepurpose of redemption, generate rewards, provide a point of sale deviceor otherwise participate in the exchange of goods, services orexperiences for currency and/or the like. In some embodiments discussedherein, the central system is referred to as a networked device.

The wallet identifying data may comprise, for example, one or more keys,random numbers, codes, and/or other types of tokens. As used herein, theterm “random” includes pseudorandom or computationally generatednumbers, keys, tokens, and the like. The wallet identifying data may beconfigured to be usable for identifying a particular consumer, aparticular consumer device of the consumer, and/or a consumer paymentaccount of the consumer configured to make payments.

The wallet identifying data may be used to encode and/or otherwisesecure messages, or simply function as random data that has no meaningwithout having secure access to the central system and more particularlyto a private key. Private information such as consumer identifying data,merchant data, financial data, transaction data, and/or other sensitive,non-random data may be secured and/or otherwise represented by thewallet identifying data, such that the wallet identifying data can bebroadcast publically (e.g., over an unsecured PAN) while mitigating therisk that non-authorized users and/or devices might obtain sensitivefinancial information about the consumer, merchant, transaction, etc.For example, the wallet identifying data may be random data associatedwith the more sensitive, less random data, and the wallet identifyingdata can be transmitted over at least some types of communication links(e.g., unsecured or less secured wireless networks or directconnections) instead of the more sensitive, less random data. Additionaldetails regarding wallet identifying data management, or walletidentifying tokens, that may be applicable to some embodiments arediscussed in greater detail in U.S. patent application Ser. No.13/764,753, entitled “Consumer Device Payment Token Management,”incorporated by reference in its entirety above.

In some embodiments, the consumer device may be configured to broadcastthe wallet identifying data it receives from the central system at 102at some and/or all times. For example, whenever the consumer device isrunning a corresponding software application or otherwise set tobroadcast (e.g., as the application runs in the background of theconsumer device's operating system), the consumer device can beconfigured to broadcast and/or otherwise send the wallet identifyingdata at 104. As discussed above, the link between consumer device andthe merchant device used to send the wallet identifying data can be anunsecure connection (such as a Bluetooth connection, public WiFiconnection, near field communication connection, etc.) without undulyraising consumer privacy risks. Nonetheless, some embodiments mayutilize a secure connection between the consumer device and the merchantdevice (e.g., Wired Equivalent Privacy (WEP), Wi-Fi Protected Access(WIPA), Wi-Fi protected Access version 2 (WPA2), etc.).

In some embodiments, the merchant device will only receive the walletidentifying data from the consumer device at 104 when the consumerdevice is in communicable proximity (e.g., within Bluetooth broadcastrange) with the merchant device. Hence, when the merchant devicereceives the wallet identifying data from the consumer device, themerchant device and/or the central system can be configured to determinethat the consumer device is physically located proximate the merchantdevice. For example, in one embodiment, the consumer may walk into amerchant shop while carrying the consumer device with an applicationrunning that causes the consumer device to broadcast the walletidentifying data. The consumer device may be configured to connect orpair with one or more merchant devices at 104, such as via a PAN (e.g.,using Bluetooth) when the consumer device comes within a communicablerange to the merchant device.

In some embodiments, the consumer device and the merchant device maycommunicate via the newly established connection or PAN and/or performpayment transactions without requiring that the consumer device have anactive connection to the central system or some other payment processingsystem (e.g., via the Internet). The connection between the consumerdevice and the central system at 102 is not required to be active orotherwise available at 104. For example, mobile broadband connectionsbetween the consumer device and the Internet may become unavailable asthe consumer device enters certain indoor merchant facilities and/orremote geographic locations.

When the merchant device establishes its own connection to the centralsystem, which in some embodiments may be permanent or episodic, themerchant device may be configured to send the wallet identifying data tothe central system at 106. In some embodiments, the merchant device andthe central system may share a relatively secure connection whencompared to that between the consumer device and the merchant device. Instill other embodiments, a dedicated secure connection between themerchant device and the central system may be maintained.

At 108, the central system may be configured to send consumeridentifying data (e.g., image data, consumer name, consumer accountinformation) and/or any other type of consumer information (e.g.,consumer preference data, consumer history data (e.g., indicating priorinteraction with particular employees), purchase history, promotionaldeals, promotional vouchers of the merchant available for purchase bythe consumer, promotional vouchers redeemable at the merchant, dine-inlocation preference data, or any other preference related information)to the merchant device. As discussed below, this information can bebased on data uploaded directly from the consumer's device(s) to thecentral system and/or collected based on the consumer's interactions(e.g., either via the consumer device or some other device), with themerchant device and/or other devices such as with a promotional system,third party system and/or separate payment processing system.

As will be apparent to one of ordinate skill in the art in view of thisdisclosure, the above described method allows for consumer identifyingdata and/or other secure information to be received at a merchant deviceupon a consumer device coming within communication proximity to themerchant device. In this embodiment, the consumer identifying data isnot transmitted from the consumer device directly to the merchant devicevia the relatively unsecure PAN connection to avoid its beingintercepted and improperly used.

At 110, the merchant device may be configured to associate the consumeridentifying data with a dine-in location. For example, if the merchantis a restaurant, the restaurant may provide dine-in locationsrepresented by tables, rooms, floor regions, seats, or the like in whicha consumer may be located while dining. The consumer may be associatedwith a particular dine-in location using one or more suitable techniquessuch as merchant assignment, dine-in location preference data of theconsumer, consumer selection, and/or location-based tracking of theconsumer device. As discussed in greater detail below, a variety ofservices may be provided to the consumer once the consumer's identity,consumer information, and dine-in location is known to the merchantdevice, and thereby also the merchant using the merchant device.

In some embodiments, different types of consumer information may bedetermined, received, and/or displayed on the merchant device throughoutthe consumer's dine-in experience. For example, table, party, and/orseating preference data may be used prior to the consumer beingassociated with a particular dine-in location, such as to place theconsumer in a seating wait list and/or otherwise assign a dine-inlocation. Food preferences and/or menu item preferences may be sentand/or displayed subsequent to seating but prior to ordering tofacilitate menu item ordering. These examples, as well as others, aredescribed in further detail below.

Secure Payments Overview

FIG. 1 b shows a flow chart of an example method 120 for facilitating afinancial transaction between the consumer and the merchant, inaccordance with some embodiments. Method 120 is meant to show a highlevel example, while some of the other processes flows discussed hereinshow more detailed examples. In some embodiments, the wallet identifyingdata may be further associated with and/or configured to be usable foridentifying a consumer payment account. The consumer payment account maybe configured to make payments, such as to a merchant account, anemployee account, and/or any other type of suitable account configuredto receive payments. While method 120 is described herein as beingdirected to payments from consumer to merchant, the consumer deviceand/or consumer payment account may also be configured to receivepayments in some embodiments. In some embodiments, method 120 may beperformed whenever a consumer customarily provides payment at a dine-inrestaurant, such as upon the completion of a meal or after the orderingof menu items.

At 122, the merchant device may be configured to send a transaction datato the consumer device. For example, the transaction data may include apayment amount based on one or more menu items that are placed on arestaurant tab (e.g., as identified by a restaurant tab identifier).“Menu items,” as used herein, may refer to any type of item that isavailable for purchase at a restaurant (e.g., food, drinks, customizedorders, off-menu items, merchandise, services, special accommodations,etc.). The restaurant tab may be associated with the consumer, such asvia the wallet identifying data and/or consumer identifying data. Assuch, the restaurant tab may also be associated with the dine-inlocation as described in method 100.

In some embodiments, the merchant device may be configured to receivemenu item data indicating one or more menu items (e.g., via merchantinput), associate the menu item data with the restaurant tab, determinethe payment amount for the one or more menu items, and send the paymentamount to the consumer device at 122. Additionally and/or alternatively,the consumer device may be configured to perform one or more of thefunctions related to generating the payment amount (e.g., order viaconsumer device).

At 124, the consumer device may be configured to send consumer approvaldata indicating approval of the proposed transaction (e.g., that whichis embodied by the transaction data). As discussed below in greaterdetail, in some embodiments, the consumer device may be furtherconfigured to use wallet identifying data or a private key associatedwith the wallet identifying data to create the consumer approval data.In one embodiment, this consumer approval data may consist of anelectronic signature created by appending a private key associated withthe wallet identifying data to a data string representing thetransaction data and then performing an algorithmic transformation, suchas a one way hash of the private key appended data string. In someembodiments, the wallet identifying data used at 124 may be the same asthe wallet identifying data sent to the merchant device at 104 of method100. The communication between the consumer device and the merchantdevice, as well as any and/or all direct communications between theconsumer device and the merchant device, may use the PAN connectionestablished at 104 of method 100. Alternatively or additionally, theconsumer device may be configured to encrypt the transaction data andthe consumer approval data using the private key

At 126, the merchant device may be configured to generate and sendsecured payment approval data to the central system. The central systemmay use this information to determine whether to execute a payment bythe consumer to the merchant. In some embodiments, the central systemmay be configured to validate or otherwise authenticate the securedpayment approval data received from the merchant device. For example,the central system may be configured to validate and/or otherwiseauthenticate the secured payment approval data based on the walletidentifying token or associated private key (e.g., as sent to theconsumer device at 102 of method 100 and later received from themerchant device). Alternatively or additionally, the central service maybe configured to decrypt the transaction data and the consumer approvaldata using the private key in example embodiments in which the consumerdevice and/or the merchant device caused the consumer approval data, thesecured payment approval data or the like to become encrypted.

If the central system validates the secured payment approval data, thena payment confirmation may be sent to the merchant device at 128. Insome embodiments, a transaction receipt (e.g., information about theparticular transaction) and/or other receipt information may be sent tothe consumer device from the central system at 130A. The other receiptinformation can include, for example, a remaining balance and/orpurchase power after the instant transaction (e.g., the amount of moneyuntil the consumer payment account reaches the applicable creditlimit(s), the amount of money remaining in the consumer payment accountafter the transaction is processed, etc.), total spent over a givenperiod of time (e.g., the amount of money spent in an hour, day, week,etc. including the instant transaction), total spent at a given merchantand/or location (e.g., amount of money spent at the merchant over aperiod of time, amount of money spent in a city over a period of time,etc.), and/or any other purchase-related information that may be ofinterest to the consumer subsequent to a transaction (includinginformation that may help identify fraud and/or improper use of theconsumer payment account).

In addition to or instead of the receipt being sent from the centralsystem to the consumer device at 130A, a transaction receipt and/orother receipt information may be sent to the consumer device from themerchant device at 130B. The receipt information sent from the merchantdevice can be the same as or different than that sent at 130A, and/orcan be independent of or based on receipt information generated by thecentral system. For example, the merchant device can be configured tosend an independent receipt to the consumer device that the consumer canuse to verify the receipt information sent from the central system at130A. This may aid the consumer in confirming that the central systemactually charged the payment amount (and/or help the consumer identify adiscrepancy between the expected charge and the amount actuallycharged). As another example, the central system may also or insteadsend receipt information to the merchant device, which may then send thereceipt to the consumer device.

Consumer Payment Accounts

FIG. 2 a shows a flow chart of an example method 200 for accessing aconsumer payment account, performed in accordance with some embodiments.Method 200 will be described with reference to example displays 300-1200shown in FIGS. 3-12, respectively.

FIGS. 3-12 show example displays 300-1200 that may be presented by oneor more display screens of one or more machines, such as those used byconsumers, which are referred to herein as “consumer devices.” Aconsumer device may be associated with a consumer and/or be carried bythe consumer. The consumer device may be a mobile device such as asmartphone, tablet, laptop, payment device, user-identifying device,token device, PAN device, or the like.

In some embodiments, the merchant device may be a stationary devicelocated at a counter, drive through, walk through, near an entrance, orthe like. Alternatively and/or additionally, the merchant device may bea mobile device. The merchant device, when mobile, may be of a sizeand/or form that is easy to carry on a person, whether by hand or someother means (e.g., in a pocket, bag, etc.). Furthermore, the merchantdevice may include wireless communication capability and/or built-inpower source(s) such that the carrier's movement is not encumbered bywiring.

In some embodiments, a restaurant may leverage multiple merchantdevices. For example, two or more servers and/or other types ofemployees may each carry a merchant device in the course of business.For example, a server may visit various dine-in locations (e.g., tables)in the restaurant while carrying a merchant device to place consumers inthe seating wait list, determine dine-in locations, take orders, providemenu information, accept payments, or the like. Furthermore, where aplurality of merchant devices is used, the merchant devices may beconfigured to share information with each other directly (e.g., in apeer-to-peer fashion) and/or via a central system. In some embodiments,a plurality of merchant devices may be strategically placed throughoutthe merchant's shop to provide coverage for location tracking ofconsumer devices.

In some embodiments, techniques similar to those described herein withrespect to method 200 and FIGS. 3-12 may further be used for accessing amerchant and/or employee account configured to make and/or receivepayments, such as via a merchant device.

While the example displays 300-1200 are configured to be shown on asmartphone (or other device having similar dimensions), similarinterfaces may be utilized with other types of consumer devicesdiscussed herein and modified accordingly (e.g., for screen size, inputdevice compatibly, ease of use, etc.).

As discussed above, a merchant device or consumer device may refer to amobile device or a stationary device in various embodiments. Examplemobile devices may include a cellular telephone (including smartphonesand/or other types of mobile telephones), laptop, wireless POS device,tablet, wireless computing device, or the like. Example stationarydevices may include a desktop computer, work station, wired POS device,server, or the like.

In some embodiments, any suitable computing device may be configured toperform the functionalities described herein with respect to bothmerchant devices and consumer devices. For example, a device may beconfigured to make a payment (e.g., like a consumer device) and alsoreceive a payment (e.g., like a merchant device), among other thingsdescribed herein.

In some embodiments, the techniques described herein may be implementedvia one or more applications that execute locally and causes amerchant/consumer device to be configured to function as a specializedmachine. Additionally or alternatively, cloud-based, multi-tenant,thin-client, and/or other types of networked service techniques may beused. For example, one or more functionalities described herein as beingperformed by a merchant device or consumer device may execute on aremote device, such as a server and/or other networked machine. Userinput information may be generated by and sent from themerchant/consumer device to the remote device, while visual and/or audioinformation is sent from the remote device to the merchant/consumerdevice.

Turning back to FIG. 2 a, method 200 shown therein may start at 202 andproceed to 204, where a consumer device may be configured to provide alogin display. For example, FIG. 3 shows login display 300 that may bedisplayed by the consumer device. Login display 300, like some or all ofthe other displays discussed herein, may be accessed by virtually anymethod, such as an application executing locally. Alternatively and/oradditionally, login display 300 may be accessed from one or more servers(e.g., central server 2704 shown in FIG. 27) via a web browser, such asby entering an address (e.g., a uniform resource locator (“URL”)address) into the web browser's location bar. Login display 300 may beconfigured to allow a consumer to create a consumer payment accountand/or sign in to an existing consumer payment account. As such, logindisplay 300 may include create account selection 302 and sign inselection 304.

At 206, the central system may be configured to determine whether theconsumer has provided login data for the consumer payment account. Forexample, the consumer may select sign-in selection 304 in login display300 to indicate a desire to sign-in to a preexisting consumer paymentaccount. In response, the consumer device may be configured to acceptlogin data (e.g., a username, password, biometric identifier, etc.) forthe consumer payment account. For example, login input display 400, asshown in FIG. 4, may be configured to accept the login data. Theconsumer may enter a username to username field 402, a password topassword field 404, and submit information (e.g., to the central system)by selecting login selection 406. Alternatively and/or additionally, apin number or some other form of identification or authentication may beused. As such, login data as used herein is not limited to embodimentsthat include a username and password.

If the consumer provides login data at 206, method 200 may proceed to208. At 208, the central system may be configured to determine whetherthe login data is valid. For example, the login data received from theconsumer device may be compared with login data stored in one or moredatabases (e.g., central database 2702 shown in FIG. 27).

In some embodiments, the central system may be configured to determinewhether the consumer has provided third party login data for a thirdparty account. For example, the consumer may select third party loginselection 408 in login input display 400, which may allow the consumerto enter the third party login data (e.g., a username and password forthe third party account).

The third party account may be any type of account that is provided byone or more third party servers (e.g., third party system 2712 shown inFIG. 27). As will be discussed in greater detail with respect to FIG. 2b, the consumer may associate one or more third party accounts with theconsumer payment account, allowing the consumer to access the consumerpayment account via the third party account (e.g., by logging in and/orotherwise authenticating with third party login data). Example thirdparty accounts may include an email account, a social networkingaccount, an account provided by a merchant, a banking account, etc.

If the employee provides the third party login data, a determination maybe made as to whether the third party login data is valid at 208. Forexample, the central system may be configured to send the third partylogin data to an appropriate third party server/system (e.g., with alogin request). The central system may be further configured to receivean indication regarding whether the login data is valid or invalid inresponse. As such, some embodiments may allow the consumer to access theconsumer payment account via one or more different third party accountsand via providing third party login data.

If the login data is determined to be valid at 208, method 200 mayproceed to 210, where the central system may be configured to provideaccess to the consumer payment account. As will be discussed in greaterdetail, the consumer device may be configured to, among other things,make payments via the consumer payment account, associate one or morepayment destinations and/or sources with the consumer payment account,and/or view confirmations (e.g., receipts or summaries) of paymentsafter receiving access to the consumer payment account.

If the login data is determined to be invalid at 208, method 200 mayreturn to 206 where a determination may be made as to whether theconsumer wants to make another attempt at providing login data for theconsumer payment account. In some embodiments, the consumer paymentaccount (e.g., as identified by username field 202) may be locked outafter a certain number of unsuccessful login attempts.

Returning to 206, if the consumer does not provide login data, method200 may proceed to 212. At 212, the central system may be configured toallow the consumer to create a new consumer payment account. Asdiscussed above, the consumer may select create account selection 302 atlogin display 300. Responsive to the selection, the central system maybe configured to provide interfaces (e.g., displays 500-1200 shown inFIGS. 5-12) to the consumer device for creating the consumer paymentaccount, which will be described in further detail with respect toexample method 220 shown in FIG. 2 b. After creating the consumerpayment account, the consumer device may be allowed to access theconsumer payment account using method 200. Method 200 may end at 214.

FIG. 2 b shows a flow chart of an example of a method 220 for creating aconsumer payment account, performed in accordance with some embodiments.Method 220 may begin at 222 and proceed to 224, where the central systemmay be configured to receive login data for the consumer payment accountfrom the consumer device. FIG. 5 shows an example create account display500 that may be presented by the consumer device, such as on a displayscreen. Create account display 500 may include name field 502, emailaddress fields 504, and password field 506. In some embodiments, anemail address entered into email address fields 504 may be used as theusername for the consumer payment account (e.g., at username field 402,as shown in FIG. 4). Alternatively and/or additionally, the consumer mayenter a username that is different from the email address. The consumerdevice may be configured to send the login data to the central systemresponsive to the consumer selecting continue selection 508.

In some embodiments, a different consumer device may be used to createthe consumer payment account in method 220 than to access the consumerpayment account in method 200. For example, the consumer device used tocreate the consumer payment account may be stationary device (e.g., ahome desktop) of the consumer while the consumer device used to accessthe consumer payment account may be a mobile device. In another example,different mobile devices of the consumer may be used. For example, theconsumer may own multiple consumer devices that may be used to create,access, and/or make payments with the consumer payment account.

At 226, the central system may be configured to associate the login datareceived from the consumer device with a consumer payment account. Forexample, associations between the login data may be stored in the one ormore databases (e.g., central database 2706 shown in FIG. 27). As such,the consumer may provide the login data to receive access to theconsumer payment account and/or associated data from any consumer devicehaving access to the central system in some embodiments. In someembodiments, a consumer may use a single consumer device. For example,the consumer device may have a consumer device identifier that is alsoassociated with the consumer identifying data and/or wallet identifyingdata at the central system such that devices that do not have theconsumer device identifier are inoperable. Additionally and/oralternatively, multiple consumer devices with different consumer deviceidentifiers may be associated with the consumer identifying data and/orwallet identifying such that the multiple consumer devices, but no otherdevices, may be used.

At 228, image data representing a picture of the consumer may beassociated with the consumer payment account. For example, the consumerdevice may be configured to display add photo display 600 responsive tothe consumer selecting continue selection 508 in create account display500. In some embodiments, the consumer device may include and/orotherwise be configured to control an image capturing device. The imagecapturing device may be any device configured to be able to capture theimage data, such as a camera, a webcam, video recorder, etc. As such,the consumer device may be configured to allow the consumer to capturethe image data by selecting take picture selection 602. Additionallyand/or alternatively, the consumer may be allowed to choose existingimage data (e.g., an image taken at an earlier time and stored) forassociation with the consumer payment account, such as by selectingupload image selection 604.

FIG. 7 shows an example confirm photo display 700 that may allow theconsumer to review captured and/or existing image data, in accordancewith some embodiments. For example, the image data may be shown atconsumer image display 702. If the image data is unsatisfactory, theconsumer may select retake selection 704, which may cause the consumerdevice to redisplay add photo display 600 in response. If the image datais satisfactory, the consumer may select use photo selection 706. Theconsumer device may be configured to send the image data to the centralsystem responsive to the selection.

Returning to FIG. 2 b, at 230, the central system may be configured toassociate one or more payment sources with the consumer payment account.A payment consumer, as used herein, refers to an account that isconfigured to make payments. However, in some embodiments, the paymentsource may also be configured to receive payments.

In some embodiments, the payment source may be a financial account, suchas a credit card account, checking account, debit account, directdeposit account, third party payment account, savings account, bankaccount, internet payment account, or the like. In that sense, “paymentsource,” as used herein, may refer to any type of account capable ofbeing associated with a currency balance (e.g., dollars, credits, etc.),receiving a payment that increases the balance, and/or providing apayment that decreases the balance.

FIG. 8 shows an example add payment destination display 800 that mayallow the consumer device to send account source data to the centralsystem, in accordance with some embodiments. The consumer may enter aname and address at 802 and 804, respectively. The consumer may furtherselect enter payment source selection 806, which may allow the consumerto enter a credit card account as a payment source. A credit cardaccount is only an illustrative example, and the techniques disclosedherein may be applicable to other types of payment sources.

Upon selecting enter payment source selection 806, the consumer devicemay be configured to allow the consumer to scan a credit card. Forexample, the employee may hold a credit card to an image capturingdevice that may be configured to capture the credit card as image data,as shown in credit card capture display 900 in FIG. 9. The image datamay be processed (e.g., using optical character recognition (“OCR”)) toextract account source data such as credit card number, expiration dateand/or credit verification value (or “CVV”), among other things (e.g.,name, address, etc.). One example of software that may provide creditcard capturing and account source data extraction with a mobile devicecamera is card.io. As discussed above, other payment sources may be usedsuch as accounts associated with debit cards, checking accounts, onlineaccounts, or payment cards in some embodiments. Furthermore, othertechniques for automatically reading payment source data from tangibleforms of payment may be used instead of, or in addition to, OCR. Forexample, a barcode reader device that reads magnetic data when theconsumer swipes an instrument through the magnetic stripe reader devicemay be used.

Additionally and/or alternatively, the consumer may select entermanually selection 902, which may cause the consumer device to displaymanual entry display 1000, as shown in FIG. 10. The consumer may enteraccount source data such as a routing number at 1002, an account numberat 1004 and a bank name at 1006. In some embodiments, extracted accountsource data from the image data may be used to automatically populatethese fields, allowing the consumer to correct any mistakes (e.g., anOCR error). The consumer may return to credit card capture display 900via camera selection 1008. The consumer may also submit the enteredaccount source data by selecting submit selection 1010.

FIG. 11 shows an example confirm payment source display 1100, inaccordance with some embodiments. Confirm payment source display 1100may be shown, for example, after the central system has validated theaccount source and/or account source data. The consumer may add apayment source (and/or destination) and/or replace the payment sourcewith a different payment source, such as by selecting change cardselection 1110. The consumer may also indicate that the name at 1102,address at 1104, and/or entered account information at 1106 is correctby selecting continue selection 1108.

Returning to FIG. 2 b, at 232, the central system may be configured tomake a determination as to whether to associate one or more third partyaccounts to the consumer payment account. In some embodiments,connecting a third party account may allow a consumer to login to theconsumer payment account via the third party account, as discussed aboveat 206 of method 200. Additionally and/or alternatively, third partyaccount data (e.g., user profile, social network data, etc.) may be usedto generate, at least in part, a consumer profile that may be presentedto merchant devices. For example, the consumer may use third partyaccount connection display 300 to associate a third party account (e.g.,a social network account) by selecting connect account selection 1202 inregistration completion screen 1200.

At 234, the consumer device may be configured to prompt the consumer forthird party login data, which may be sent to the central system. Thecentral system may be configured determine whether the third party logindata is valid at 236, which may include communicating with a third partysystem/server.

If the third party login data is valid, method 220 may proceed to 238,where the third party account may be associated with the consumerpayment account. If the third party login data is invalid, method 220may return to 232, to determine whether the consumer is still interestedin connecting a third party account. If the consumer is not interestedin associating a third party account with the consumer payment account,method 220 may end at 240. After consumer payment account creation, thecentral system may be configured to provide access to the consumerpayment account, associated data, and/or functionality. For example, theconsumer may select go to application selection 1204 in registrationcompletion screen 1200, as shown in FIG. 12.

As discussed above, the consumer may be associated with a consumerprofile that includes consumer information. In some embodiments, some orall of the consumer information may be viewable by merchants, such as anemployee in the course of providing consumer assistance. Therefore, theconsumer device and/or central system may be configured to allow theconsumer to keep a separation between third party account information(e.g., personal social network information) and the consumer profile.For example, only limited types of data, such as consumer name, may beused in generating the consumer profile. Furthermore, the consumer maychoose not to connect any third party account. In some embodiments, theconsumer may select consumer profile selection 1206 in registrationcompletion screen 1200 to create and/or edit the consumer profile (e.g.,regardless of whether there is a connected third party account).

Dine-in Location Functionality

FIG. 13 a shows a flow chart of an example data flow represented bymethod 1300, which can result in associating a consumer with a dine-inlocation, performed in accordance with some embodiments. Method 1300 maybe performed by a consumer device (e.g., consumer device 2712 shown inFIG. 27), a merchant device (e.g., merchant device 2710) and one or morenetworked machines (e.g., central server 2706). In some embodiments,method 1300 may be performed after a consumer has logged in and/orotherwise authenticated with the central system to access a consumerpayment account configured to make payments, as discussed above inconnection with method 200.

At 1302, the central system may be configured to send wallet identifyingdata (with corresponding private keys) to the consumer device. As such,the consumer device may be configured to store the wallet identifyingdata. “Wallet identifying tokens” or “wallet identifying data,” as usedherein, may refer to any type of data that may be used to secure datatransfers between the consumer device and the merchant device and enablethe consumer device to cause the merchant device to receive secureinformation about the consumer (and/or the consumer's payment account)from the central system. For example, wallet identifying data mayinclude, or may be based at least partially on, a random or pseudorandomcode, number, etc., generated by the central system. In variousembodiments, the central system may be configured to associate thewallet identifying data with consumer identifying data that identifies aconsumer, a consumer device and/or a consumer payment account. Thisassociation may be stored to a memory or database that is accessible bythe central system.

In some embodiments, the wallet identifying data may be associated witha private key. For example, the wallet identifying data may beconfigured to be usable as a public key that may be passed to otherdevices (e.g., a consumer device, a merchant device, a central system,etc.) to validate or authenticate various types of data. The private keymay be used by the central system to correlate wallet identifying data(e.g., a wallet identifying token) with consumer identifying data and tovalidate and/or otherwise verify secured payment approval data such thatthe data may be relied upon as authentic and, thus, processed orotherwise used. The private key may be kept secret by the central systemand/or securely shared with only devices (e.g., consumer devices)authorized to use wallet identifying data and private keys as discussedin greater detail herein. In some embodiments, a wallet identifying dataand a corresponding private key may be generated together and/ormathematically related such that determining the private key from thewallet identifying token (and vice versa) is very difficult, if notimpossible, and extremely time consuming or prohibitively expensive.

In some embodiments, some or all of the messages sent by the consumerdevice to the merchant device (e.g., via an unsecured direct wirelessconnection) may be secured with wallet identifying data. Messages thatare signed with the wallet identifying data and/or a private key (e.g.,the wallet identifying data and/or private key is appended or otherwiseincluded with the message) may be used to identify the message senderand/or to authenticate the message sender (e.g., to prove that thesender is identified correctly). For example, if the central systemreceives a signature from a merchant device in association with aproposed consumer device payment that does not match valid (e.g.,non-expired or otherwise expected) wallet identifying data previouslysent to the consumer device, the payment may be denied.

In various embodiments, wallet identifying data and/or private keys maybe used for a number of purposes including identifying a consumer,sending secure data, identifying a consumer payment account, signingmessages by the consumer device that demonstrate consumer consent (e.g.,for a payment), proving authenticity of messages, and/or encryptingmessages.

Wallet identifying data (and associated private keys) may be sent to theconsumer device at virtually any time. For example, the consumer devicemay be a smart phone that is configured to download an application fromthe central system (e.g., an online store of smart phone applications),and the downloading, installation and/or execution of the applicationcan cause the consumer device to receive the wallet identifying data.Additionally and/or alternatively, wallet identifying data may bedownloaded by the consumer device at a later time, such as at theconsumer's request, at the creation of a consumer payment account, via acentral system push, on a schedule basis (e.g., each day, each hour,each month, etc.), upon entering a certain proximity to a merchantdevice, upon establishing a connection with the central system, in thecourse of a transaction, upon the occurrence of a specified event orcondition, combinations of the above. etc. In some embodiments, newwallet identifying data may replace and/or be added to existing walletidentifying that is stored in the consumer device. This refreshing ofwallet identifying data may ensure additional security, for example,because wallet identifying data may be time-stamped or otherwise may beallowed to expire or become inoperable at the central system, merchantdevice, and/or consumer device. In some embodiments, some or all of thediscussion herein regarding wallet identifying data may also apply tomerchant identifying data and merchant devices.

At 1304-1308, the consumer device and the merchant device may beconfigured to form a connection. In some embodiments, the connection maybe formed without the consumer device and/or the merchant device havingactive Internet access at the time of the connection (e.g., an activeconnection to the central server). For example, the connection may be awireless connection over a PAN (e.g., via PAN network 2416 shown in FIG.24). Some suitable PAN protocols may include Bluetooth, Infrared DataAssociation (irDA), wireless USB, ZigBee, WiFi, and Z-Wave. In someembodiments, other types of connections between the consumer device andmerchant device, such as direct wire, Internet, near fieldcommunications and/or radio frequency identification technologies, maybe used. A “PAN connection,” as used herein, may refer to any directconnection between the consumer device and the merchant device (e.g.,via network 2716 rather than network 2708, as shown in FIG. 27).Similarly, a “PAN,” as used herein, may refer to any suitable networkfor the direct connection.

Depending on the protocol used, at 1304, the consumer device may beginannouncing a consumer service to other devices, such as the merchantdevice. For example, a process and/or application may configure theconsumer device to broadcast (e.g., via Bluetooth) one or more suitablemessages. FIG. 19 shows an example consumer service menu display 1900that may be displayed on the consumer device. The consumer may usesettings selection 1902 to enable or disable the announcing of theconsumer service.

In some embodiments, the consumer service may include one or morebackground processes that may run while the consumer device is locked,in a low-power mode, and/or executing other applications in theforeground. In some embodiments, the one or more broadcasted messagesmay include wallet identifying information and/or be encrypted usingwallet identifying information.

At 1306, the merchant device may begin discovering the consumer service.For example, a process and/or application may execute on the merchantdevice that configures the merchant device to discover other devices,such as the consumer device, that are currently announcing the consumerservice. In some embodiments, discovery of the consumer service by themerchant device may be initiated after an employee has logged in,authenticated, or otherwise enabled such functionality on the merchantdevice.

In some embodiments, the consumer device may be configured to discoverthe consumer service while the merchant device may be configured toannounce the consumer service. Additionally and/or alternatively, bothdevices may be configured to be capable of announcing and discoveringthe consumer service. For example, both devices may discover compatibledevices and/or be discovered by compatible devices.

At 1308, a connection between the merchant device and the consumerdevice may be created. For example, the consumer device and merchantdevice may come within a certain discovery range, such as when aconsumer carrying the consumer device enters the merchant's shop. Insome embodiments, the discovery range may be set by the merchant deviceand/or the consumer device and/or by the range at which the devices canbe located from each other and still be able to communicate (e.g.,Bluetooth capable devices may have a communicable range between 10 and100 meters, depending on the type of device(s) being utilized).

In some embodiments, some or all of the messages used to form theconnection between the consumer device and the merchant device at1304-1308 may be encrypted and/or signed. For example, messages sentfrom the consumer device may be encrypted and/or signed with walletidentifying data. Additionally and/or alternatively, messages sent fromthe merchant device may be encrypted and/or signed with merchantidentifying data and/or received wallet identifying data. In someembodiments, messages used to form the connection may not include anyconfidential information. Such messages, for example, may be leftunsecured.

At 1310, the consumer device may be configured to send the walletidentifying data to the merchant device. For example, the walletidentifying data may be used as a secure reference for requests by themerchant device to the central system for additional consumer data. Insome embodiments, the consumer's name, URL for accessing the image datarepresenting a picture of the consumer (e.g., as associated with thepayment account at 210 of method 200), the image data itself, and/orother suitable consumer identification information may be sent with thewallet identifying data (e.g., as one or messages that are encrypted,signed, or simply unsecured). In some embodiments, the walletidentifying data sent to the merchant device at 1310 may be one ofmultiple wallet identifying data that the consumer device received fromthe payment server at 1302.

As discussed above, the wallet identifying data may provide a referenceto consumer data (e.g., consumer identifying data and/orconsumer-related data) available from the central system. As such, thewallet identifying data may be sent to the merchant device in place ofactual consumer data that may be readily stolen by an unauthorizeddevice via the PAN connection. Furthermore, the central system may beconfigured store the wallet identifying data in association withconsumer identifying data, consumer payment account data, a consumerdevice identifier, and/or other consumer-related data prior to sendingthe wallet identifying data to the consumer device at 1302.

At 1312, the merchant device may be configured to send merchant data tothe consumer device. For example, the merchant data may include merchantidentifying data, or other data, that indicates the merchant's identityto the consumer device. The merchant data may further includeinformation about the merchant, such as menu items, items for sale(e.g., products, services, etc.), promotional deals, promotionalvouchers of the merchant available for purchase, purchased promotionalvouchers redeemable at the merchant, sales, etc. FIG. 20 shows anexample merchant main display 2000, in accordance with some embodiments.Merchant main display 2000 may be shown on the consumer device at 1312and may include the merchant data, such as merchant name at 2002, dealsat 2004, and menu items at 2006. In some embodiments, some or all of themerchant data may be stored in central database 2702 and provided toconsumer device 2712 via merchant device 2710, as shown in FIG. 27.

Additionally and/or alternatively, the consumer device may accessmerchant main display 2000 and/or its data via the central system (e.g.,at the merchant shop or otherwise). For example, some or all of themerchant data may be provided to consumer device 2712 via network 2708,as shown in FIG. 27. In some embodiments, a consumer may search and/orbrowse a list for merchants (e.g., using search field 1904 of consumerservice menu display 1900). Upon selecting a particular merchant, amerchant main display 2000 for the merchant may be shown on the consumerdevice. In some embodiments, the merchant data sent from the merchantdevice at 1312 may include merchant identifying data but no additionalmerchant information. As such, the consumer device may be configured torequest the additional information from the central system based on themerchant identifying data.

At 1314, the merchant device may be configured to establish a secureconnection with the central system (e.g., via network 2708 shown in FIG.27). For example, an employee may provide login data to the centralsystem that may be used to identify and authenticate the employee and/ormerchant. As discussed above, the secure connection between the merchantdevice and the central system may be established at any suitable time,such as before the merchant device has connected with the consumerdevice at 1308, or before the consumer device enters within communicableproximity to the merchant device. In some embodiments, the merchantdevice may connect to the central system via a local area network (LAN)(e.g., via one or more wireless routers for mobile devices or Ethernetif the merchant device is wired) that is connected to the Internet.Additionally and/or alternatively, the merchant device may connect tothe central system without using a local access point, such as via amobile broadband connection.

At 1316, the merchant device may be configured to send the walletidentifying data received from the consumer device at 1310 to thecentral system. For example, the wallet identifying data may be sent viathe secure connection established at 1314. As discussed above, thewallet identifying data may be used by the central system to identifythe consumer, consumer device, and/or the consumer payment accountassociated with the consumer.

At 1318, the central system may be configured to validate the consumer,such as by using the wallet identifying data. For example, the centralsystem may determine whether the wallet identifying data sent to theconsumer device at 1302 matches or otherwise corresponds with the walletidentifying data received from the merchant device at 1316. In someembodiments, the central system may be configured to ensure that thewallet identifying data received from the merchant device at 1316originated from a consumer device (e.g., at 1310) that is authorized touse the consumer payment account. As discussed above, authorizedconsumer devices may include consumer device identifiers that areassociated with the wallet identifying at the central system. As such,the consumer device may also be configured to send a consumer deviceidentifier to the merchant device and the merchant device may beconfigured to send the consumer device identifier to the central system.

In some embodiments, the central system may be configured to extractsome or all of the consumer data (e.g., the consumer's identity) fromthe wallet identifying data (e.g., by using one or more tokens or keysthat correspond with the wallet identifying data), such as when theconsumer device used the wallet identifying data to encode consumer dataor otherwise attached with consumer data with the wallet identifyingdata.

At 1320, the central system may be configured to send consumeridentifying data associated with the wallet identifying data to themerchant device. In some embodiments, the consumer identifying data mayinclude image data, consumer name, a consumer identifier, or the likethat may be kept secure by the central system (e.g., rather than beingstored in the consumer device and sent over the PAN connection tomerchant devices). As discussed above, the association between thewallet identifying data and the consumer identifying data (as well asconsumer-related data or other data of the consumer) may be stored inone or more databases (e.g., central database 2702 shown in FIG. 27). Assuch, the central server may be configured to request the consumeridentifying data from the central database based on the walletidentifying data received from the merchant device.

In some embodiments, the merchant device may be configured to receiveother types of consumer data from the central system at 1320. Theconsumer data may include, for example, consumer profile data, consumerpayment account data, dine-in preference data, third party account data,menu item purchase history data, social network data, consumerpreference data, promotional vouchers of the merchant available forpurchase, promotional vouchers redeemable at the merchant, etc. As willbe discussed in further detail below, some or all of the consumer datamay be further used to enhance the consumer's dine-in experience.

In some embodiments, the merchant device may be further configured tosend some of the consumer information received from the central systemto the consumer device. Additional details regarding deal vouchers andrewards that may be sent to the consumer device in some embodiments arediscussed in U.S. Provisional Patent Application No. 61/715,230,entitled “Consumer Presence Based Deal Offers,” incorporated byreference in its entirety above.

At 1322-1328, the consumer (e.g., via consumer identifying data and/orwallet identifying data) may be associated with a dine-in location. Adine-in location, as used herein, refers to a unit of location that maybe assigned to a consumer, group, and/or restaurant tab. For example, adine-in location may be a table at a restaurant that includes aplurality of tables, each table being a different dine-in location.Here, each table may be uniquely identified with a table identifier thatmay be associated with consumer, group, and/or restaurant tabidentifier. Other types of dine-in locations may include, for example,individual seats, bar stools, or the like.

At 1322, the consumer device may be configured to send dine-in locationpreference data. The dine-in location preference data may be used toplace the consumer in a seating wait list in accordance with consumerpreference. The seating wait list, as used herein, refers to a list ofconsumers (or groups) that are waiting for an available dine-inlocation. For example, restaurants that are particularly busy may nothave sufficient seating to meet full demand at all times. As such, themerchant device may be configured to place consumers on the seating waitlist. For example, the merchant device may be configured to manageseating wait list data that includes queue of consumers (e.g., asidentified by consumer identifying data and/or wallet identifying data).In some embodiments, the merchant device and/or central system may beconfigured to send a request for the dine-in location preference data tothe consumer device.

The dine-in location preference data, for example, may include anyinformation that may be used in placing the consumer and/or associatedparty into a suitable and/or preferred position within the seating waitlist. As such, the consumer device may be configured to send, as dine-inlocation preference data, the number of people in the consumer's party,the number of adults, number of children, preferred seating type (e.g.,table, barstool, window seat, booth, location within restaurant,television-viewing, balcony, porch, indoor, outdoor, smoking,non-smoking, etc.), among other things. In some embodiments, dine-inlocations may each be associated (e.g., via table identifiers if thedine-in locations are tables) with properties such that the dine-inlocations may be matched based on the dine-in location preference data.For example, a dine-location may have a capacity property whichindicates the maximum number of consumers that may be seated at thedine-in location. As such, dine-in location preference data thatindicates a group of four can be matched with dine-in locations thathave a capacity of at least four consumers.

In some embodiments, the merchant device may be configured to receivesome or all of the dine-in location preference data from the centralsystem. The central system may be configured to store dine-in locationpreference data preference data received from prior interactions with aconsumer device and/or merchant device. For example, dine-in locationpreference data may be associated with the wallet identifying dataand/or consumer identifying data at the central system.

At 1324, the merchant device may be configured to update the seatingwait list data. For example, when a dine-in location becomes available,the seating wait list data may be updated accordingly. A suitableconsumer (e.g., based on the dine-in location preference data) may bemoved up in the queue. Furthermore, consumers may indicate a change intheir dine-in location preference data (e.g., change in party size,preferred location, cancelation, etc.), which may be used to update theseating wait list. In some embodiments, the merchant device may beconfigured to leverage a plurality of queues. For example, seating fortwo may have a different queue than seating for six, or the like.

At 1326, the merchant device may be configured to determine a dine-inlocation for the consumer. For example, when the consumer reaches thetop of the queue for a suitable dine-in location, the consumer may beassigned to the dine-in location. As such, the seating wait list datamay be updated accordingly to reflect that the consumer is no longerwaiting to be seated.

At 1328, the merchant device may be configured to send an indication ofavailable seating to the consumer device. For example, the merchant mayprovide for a lobby or other waiting area within which the consumer maywait for seating. When seating becomes available, the indication as suchmay be sent to the consumer device. Method 1300 may then end.

In some embodiments, the consumer device may be configured to allow theconsumer to order one or more menu items while the consumer is waitingin the seating wait list. For example, the consumer device may beconfigured to access the menu via the connection with the merchantdevice and/or via the Internet (e.g., with the central system).Furthermore, one or more promotional offers (e.g., on sale menu items,limited time items, reward tracking items, etc.) may be presented to theconsumer device. Techniques for providing online ordering of menu itemsare discussed further in U.S. patent application Ser. No. 13/657,728,entitled “Facilitating Online Transactions,” incorporated by referencein its entirety above.

FIG. 13 b shows a flow chart of an example method 1330 for determining adine-in location, performed in accordance with some embodiments. Themerchant device may be configured to determine the dine-in locationbased on the location of the consumer device. For example, somerestaurants may leverage consumer self-seating (e.g., method 1300 at1322-1328 is not performed) and/or allow a consumer to relocate to adifferent dine-in location (e.g., method 1330 may be performed aftermethod 1300).

Method 1330 may begin at 1332 and proceed to 1334, where the merchantdevice may be configured to receive one or more wireless communicationsfrom the consumer device. In some embodiments, any of the communicationsdiscussed herein between the merchant device and consumer device, suchas via the PAN connection or any other suitable connection, may be used.In some embodiments, multiple merchant devices and/or other devices maybe used. For example, the multiple merchant devices may be strategicallyplaced to act as nodes that provide sufficient coverage within therestaurant.

At 1336, the merchant device may be configured to determine locationdata based on the one or more wireless communications received from theconsumer device. The location data, for example, may be determined basedon communications between the consumer device and a plurality ofmerchant devices strategically placed within the restaurant to providesufficient geographic coverage. As such, techniques such astriangulation, received signal strength indication (RSSI) data, and/orthe like may be used to determine the location data. The communicationsfrom the consumer device to the plurality of merchant devices may be viathe PAN connection (e.g., Bluetooth).

In some embodiments, a dine-in location may include a location devicelocated at and/or near the dine-in location and configured tocommunicate with the consumer device to determine the location data.Techniques such as radio frequency identification (RFID), near fieldcommunication (NFC), Quick Response (QR) code, RSSI, wireless local areanetwork (WLAN), ZigBee, or the like may be used. A location device(e.g., a merchant device or other suitable type of device of themerchant) may be located each, or a plurality of, dine-in locations. Forexample, the consumer device may be configured to generate and display aQR code that may be scanned with a location device at a dine-inlocation. Additionally and/or alternatively, the location device may beconfigured to automatically detect the consumer device when the consumerdevice comes within a certain proximity to the location device at adine-in location, such as via NFC, RSSI, or RFID.

At 1338, the merchant device may be configured to determine the dine-inlocation based on the location data. For example, the merchant devicemay be configured to match the dine-in location that is nearest to thelocation indicated by the location data. Furthermore, the merchantdevice may utilize existing dine-in location information, such as byremoving dine-in locations associated with other consumers from a poolof possible dine-in locations.

In some embodiments, the consumer device may be configured to determinethe location data (e.g., based on communications received from one ormore merchant devices) and send the location data to the merchantdevice. Here, the merchant device may be configured to determine thedine-in location based on the location data received from the consumerdevice.

FIG. 14 shows a flow chart of an example method 1400 for facilitatingconsumer and merchant dine-in interactions, performed in accordance withsome embodiments. As such, method 1400 may be performed after method1300 and/or 1330, such as after the consumer has been associated with adine-in location.

Method 1400 may start at 1402 and proceed to 1404, where the merchantdevice may be configured to provide a floor plan, with at least someconsumer identifying data associated with the dine-in location withinthe floor plan, to a display device. FIG. 16 shows an example floor plandisplay 1600 that may be displayed on the display of the merchantdevice. In some embodiments, floor plan display 1600 may be part of agraphical user interface that may also be configured to provide, amongother things discussed herein, POS functionality.

Floor plan display 1600 includes a plurality of dine-in locations shownin a graphical layout as tables, where each table is identified with atable identifier. For example, table 1602 is shown with table identifier1604 having a value of 70. Furthermore, table 1602 is includes consumeridentifying data such as consumer name at 1606 and consumer image at1608. The other shown dine-in locations, such as table 1610 does notinclude consumer identifying data, which may indicate that the table isnot associated with a consumer (e.g., available for seating).

At 1406, the merchant device may be configured to receive consumerinformation associated with the consumer identifying data. For example,the consumer information may be sent from the central system.Alternatively and/or additionally, the consumer information may bereceived from the consumer device. The consumer information received at1406 may include any type of data that may be suitable, useful, orhelpful in providing service to the consumer while seated at the dine-inlocation. Example consumer information may include, but is not limitedto, dine-in preference data configured to facilitate customized diningservice, menu item preference data (e.g., favorite menu items, drinks,allergies, etc.), consumer history data (e.g., indicating priorinteraction with particular servers), purchase history, promotionalvouchers available for purchase, purchased promotional vouchersredeemable, recommended menu items, table setting preference data, etc.

At 1408, the merchant device may be configured to receive, from theconsumer device, consumer request data indicating a request for merchantassistance at the dine-in location of the consumer. In some embodiments,the consumer request data may be transmitted wirelessly, such as via thePAN connection between the consumer device and the merchant device. Theconsumer request data may indicate, for example, that the merchant isrequested for a variety of reasons. The merchant may leverage thereceived consumer request data to send an employee (e.g., a server) tothe dine-in location. Additionally, the consumer request data mayindicate the nature of merchant assistance that is required. Forexample, consumer request data may further indicate that the consumer isready to pay the restaurant tab and/or requires a beverage refill,additional utensils, napkins, etc. As such, the merchant may bringrequested items to the dine-in location without having to make apreliminary information gathering visit.

At 1410, the merchant device may be configured to provide the consumerrequest data and/or consumer information to the display device. As such,a merchant that is viewing the display device may use the displayed datato assist the consumer accordingly. In some embodiments, the consumerrequest data and/or consumer information may be displayed in a commonuser interface and/or graphical display as floor plan display 1600. Asshown in FIG. 16, table 1602 in floor plan display 1600 includesconsumer request indicator 1612, which indicates that the merchantdevice has received consumer request data from the consumer device.

FIG. 17 shows an example consumer preference display 1700 that may beshown on the merchant device, such as upon a selection of table 1602 infloor plan display 1600. As shown, table 1602 includes five seatedconsumers, each with a different consumer entry within consumerpreference display 1700. For example, consumer entry 1702 may include adisplay of consumer name at 1704, consumer image at 1706,recommended/favorite items at 1708, preference information at 1710,visit count at 1712, and/or promotional deals/rewards at 1714. Virtuallyany consumer information associated with the consumer may be shown inconsumer preference display 1700. In some embodiments, the consumerdevice may be configured to allow the consumer to set what consumerinformation is available to the merchant. Additionally and/oralternatively, the merchant device may be configured to allow themerchant to set the types of consumer information that is shown, as wellas the timing of the types of consumer information shown, in consumerpreference display 1700.

In some embodiments, relevant types of consumer information (e.g.,dine-in preference data) may be displayed on the merchant devicedepending on the stage of the dine-in experience. For example, consumerinformation related to consumer table setting preferences may bedisplayed shortly after a dine-in location has been associated withconsumer identifying data such that the merchant may prepare the tableaccordingly. In another example, menu item preferences may be displayedwhen the merchant is taking orders for providing recommendations,customized orders (e.g., remove allergic ingredients), or the like.Method 1400 may then end at 1412.

Secure Payment via Consumer Device

FIG. 15 shows a flow chart of an example method 1500 for facilitatingtransactions between a consumer and a merchant, performed in accordancewith some embodiments. Method 1500 may be performed after method 1300and/or method 1400, for example, such as after consumer identifying datahas been associated with a dine-in location.

Method 1500 may begin at 1502, where the merchant device may beconfigured to associate the consumer identifying data (and/or walletidentifying data) with a restaurant tab identifier. As discussed above,a restaurant tab identifier refers to data that identifies a restauranttab. For example, one or more menu items may be placed on the restauranttab when the consumer places an order. The consumer may then pay therestaurant tab using the consumer device, such as upon completion of themeal and/or order.

At 1504, the merchant device may be configured to associate menu itemdata indicating one or more menu items with the restaurant tabidentifier. For example, the merchant device may be configured toreceive the menu item data via merchant input. The menu item data mayfurther include price data for the one or more menu items.

FIG. 18 shows an example restaurant tab display 1800 that may bedisplayed on the merchant device, in accordance with some embodiments.Restaurant tab display 1800 may be used by a merchant to add and/orremove menu items from the restaurant tab. Restaurant tab display 1800may include informational displays that in some embodiments may beselectable to access additional related data and/or functionality, suchas table identifier 1802, server identifier 1804, guest information1806, and seating status information 1808. Furthermore, restaurant tabdisplay 1800 may include selectable menu list 1810, configured to allowthe merchant to select one or more menu items for association with therestaurant tab. An example menu item is Chicken and Waffles, shown at1812 with associated price data. Selected menu items may be indicated atordered items display 1814.

In some embodiments, the merchant device may be configured to allow themerchant to access restaurant tab display 1800 and/or other suitableinterface for generating the restaurant tab by selecting a dine-inlocation (e.g., table 1602 from floor plan display 1600) and/or aconsumer (e.g., consumer entry 1702 from consumer preference display1700). The dine-in location (e.g., table identifier), consumeridentifying data and restaurant tab identifier may all be associated tofacilitate such functionality, among others discussed herein. Asdiscussed above, the consumer device may be further configure to orderone or more menu items via the Internet in some embodiments either atthe seating location, prior to being seated but at the merchant, and/orprior to arriving at the merchant (e.g., via the Internet), as discussedin greater detail in U.S. patent application Ser. No. 13/657,728,entitled “Facilitating Online Transactions,” incorporated by referencein its entirety above.

At 1506, the merchant device may be configured to determine a paymentamount based on the menu item data. For example, the payment amount maybe determined based on the price data for the one or more menu itemsassociated with the restaurant tab. In some embodiments, the paymentamount may also be displayed on the merchant device, as shown at 1816 ofrestaurant tab display 1800. In some embodiments, the payment amount mayreflect the redemption of a promotional voucher, coupon, or otherpromotional offering. For example, the value of a redeemed promotionalvoucher may be subtracted from the payment amount. Furthermore, thepayment amount may include a tax amount determined based on the totalcost of the one or more menu items associated with the restaurant tab.

At 1508, the merchant device may be configured to send the transactiondata (e.g., including the payment amount) to the consumer device. Insome embodiments, the transaction data may further include a transactionID (a unique number or code generated by the merchant device for eachtransaction), a merchant ID (a unique number or code associated witheach merchant), and/or the menu item data.

In some embodiments, the transaction data may be sent responsive to themerchant selecting send selection 1818 in restaurant tab display 1800.Additionally and/or alternatively, the merchant device may be configuredto send the menu item data indicating the one or more menu items to aticket printer and/or kitchen/bar display, such as upon selecting sendselection 1818 to facilitate menu item preparation. In some embodiments,merchant device may be configured to send the payment amount wirelesslyto the consumer device via the PAN connection between the merchantdevice and the consumer device.

In some embodiments, the consumer device may be configured to performone or more functions of the merchant device discussed above at1502-1506. For example, the consumer device may be configured toreceive, from the merchant device and/or the central system, menuinformation which may be used to associate menu item data with therestaurant tab identifier. Furthermore, some embodiments may allow theconsumer device to add and/or delete one or more menu items associatedwith the restaurant tab identifier. In some embodiments, the consumerdevice may be configured to select one or more items online, such aseven before the consumer has entered the merchant shop, as discussed ingreater detail in U.S. patent application Ser. No. 13/657,728, entitled“Facilitating Online Transactions,” incorporated by reference in itsentirety above.

In some embodiments, the merchant device may be configured to allow themerchant to select from a plurality of payment types. For example, themerchant may ask the consumer how the consumer would like to pay. Theconsumer may decide, for example, to pay by cash, credit card orotherwise without using the consumer device. As such, the merchantdevice may be configured to accept alternative forms of payment. If theconsumer decides to pay via the consumer device, the merchant may soindicate by selecting a pay-by-consumer device selection on the merchantdevice, which may cause the merchant device to send the payment amountto the consumer device.

At 1510, the consumer device may be configured to generate consumerapproval data for the payment amount. Consumer approval data, as usedherein, refers to data that is configured to provide an indication thatthe consumer has approved the payment and may refer to transaction datathat is signed using a private key associated with the walletidentifying data (e.g., as sent to the consumer device at 1310 of method1300) or otherwise secured with the wallet identifying data and/orprivate key.

In some examples, the consumer approval data, taking the form of anelectronic signature, may be generated by using an algorithmictransformation, such as hashed (e.g., using cryptographic hash functionssuch as SHA-1). In one embodiment, the electronic signature createdusing the private key associated with the wallet identifying data may bea hash of the private key and at least some portion of the transactiondata. In some embodiments, the consumer approval data may be sent to themerchant device via one or more messages that may also include thetransaction data (e.g., merchant ID, merchant payment amount, employeepayment amount, total payment amount, time of transaction, location, tipetc.) and/or the additional indication of consent. In examples, where atip or other value is added, the consumer device may include anindication of the tip, an additional authorization or may otherwisecause an indicated tip to be added to the transaction data or otherwiseprovided to the merchant device (e.g., for approval) and ultimately tothe central system. In some embodiments, the consumer approval data mayinclude consumer data (e.g., consumer name, payment source information,payment account identification, etc.).

Alternatively or additionally, in some embodiments, at least one of theone or more messages may be encrypted using the wallet identifying data.As discussed above, the wallet identifying data may be a public key forencryption with an associated private key for decryption that is storedin the central system. Alternatively and/or additionally, at least oneof the one or more messages (hashed or otherwise) may be signed usingthe wallet identifying data. For example, the wallet identifying datamay be appended or otherwise included with a message to ensure theauthenticity of the message (e.g., that the message was received fromthe consumer device). In some embodiments, both signing and encryptionmay be used.

In some embodiments, the one or more messages (encrypted, signed, hashedor otherwise) may be formatted with JavaScript Object Notation (JSON),where each piece of data is associated with a field. For example, anencrypted, hashed and/or signed message (e.g., in any order) may beincluded within a field as specified by the JSON format. Alternatively,unsecured messages may be formatted with JSON and then the formattedmassage may be hashed, encrypted and/or signed (e.g., in any order).

In some embodiments, generating the consumer approval data may includegenerating an indication of approval. FIG. 21 shows an example paymentapproval display 2100 that may be shown on the consumer device thatincludes the payment amount. Payment approval display 2100 may includesub-total display 2102, tip display 2104 (e.g., an employee paymentamount), tax display 2106 and payment amount display 2108. Furthermore,the consumer may select shopping list selection 2114 to view a listingof menu items (e.g., the one or more menu items whose price dataprovides a basis for the sub-total).

Via payment approval display 2100, the consumer device may be configuredto allow the consumer to select the employee payment amount. Forexample, the consumer may select a tip percentage using tip selection2110. Responsive to a tip selection, tip display 2106 and total amountdisplay 2108 may be updated to reflect the new tip and total amounts. Assuch, payment amount, as used herein, may further include the tipamount.

If the consumer is satisfied with the payment, the consumer may selectapprove payment selection 2112 to indicate approval of the payment.Additionally and/or alternatively, the consumer device may be configuredallow and/or require the user to provide an additional indication ofconsent. For example, the consumer may be prompted to select a box(e.g., a checkbox that indicates consent), provide login data, generatea signature (e.g., via a touch sensitive device such as a touch sensor),enter a pin number, and/or provide a biometric identifier (e.g., afingerprint, voice message, retina scan, behavioral identifier, etc.).If the consumer is not satisfied with the payment amount or otherwisedoes not approve of the payment, the consumer may select cancel orderselection 2116.

In some embodiments, the consumer device may be configured toautomatically approve the payment amount based upon satisfaction of oneor more trigger conditions. As such, the consumer device may beconfigured to allow the consumer to preapprove payments (e.g., in theform of a predetermined tip percentage for tip payments), such as evenprior to coming within proximity to the merchant device as discussed inmethod 1300.

For example, the identity of the merchant may serve as a triggercondition for automatic payment in some embodiments. The consumer may beallowed to add one or more merchants to an approved merchant list, suchas via communications with the central system. As such, upon receiving apayment request for merchant and/or employee of the merchant on theapproved merchant list, the consumer device may be configured toautomatically generate and send the payment approval data to themerchant device. The merchant list may be stored on the consumer deviceand/or the central system. In some embodiments, the consumer device maybe configured use the merchant data received from the merchant device at1312 of method 1300 to determine whether the merchant is on the approvedmerchant list.

In some embodiments, the location of the consumer device may serve as atrigger condition for automatic payment. For example, the consumerdevice may be configured to allow the consumer to simply walk out of therestaurant after completion of a meal. The location of the consumerdevice may be tracked such that the payment approval data is sent to themerchant device when the consumer device leaves the restaurant, becomesa certain distance from the merchant device, drops out of communicablerange with the merchant device, etc.

In some embodiments, reception of the payment amount by the consumerdevice may serve as a trigger condition for automatic payment.Combinations of one or more trigger conditions may be used. For example,the consumer device may be configured to send the payment approval dataonly to merchants on the approved merchant list upon receiving thepayment amount from a merchant device of the approved merchant. Otherexample trigger conditions may include merchant device location,merchant type (e.g., retailers, restaurants, etc.), the payment amount(e.g., automatically approve payments below a specified amount), aper-day cost threshold (e.g., up to $100 per day can be automaticallyapproved), etc.

In some embodiments, the consumer device may be configured to allow aconsumer to set automatic approvals on or off. Additionally and/oralternatively, a consumer may specify that only certain types oftransactions require approval. In another example, approval for aninitial payment may be required at a merchant, but not for subsequentpayments. Similarly, an approved merchant may be removed or otherwiseset such that the next and/or every transaction with the merchantrequire manual approval.

In some embodiments, the merchant device may be configured to setwhether to allow automatic payment approval by consumers based on one ormore trigger conditions. For example, the merchant device may specifythat all payments require manual approval, payments from certainconsumers require manual approval, or payments above a certain thresholdamount require manual approval, etc.

Returning to FIG. 15, the consumer device may be configured to send theconsumer approval data to the merchant device at 1512. As discussedabove, the consumer approval may provide a secure indication that theconsumer has approved the payment.

At 1514, the merchant device may be configured to generate securedpayment approval data. In some example embodiments, the secured paymentapproval data is a combination or other association of the consumerapproval data and the transaction data sent at 1508. In some examples,the consumer approval data may take the form of the secured paymentapproval data and, in such embodiments, the merchant device may functionas a pass through device.

In some embodiments, the secured payment approval data may include theconsumer approval data and the total amount (e.g., the payment amountsent to the consumer device with the transaction data plus the tipamount added by the consumer). For example, the consumer device may beconfigured to send the consumer approval data with the tip amount to themerchant device, where the tip amount is separate from the consumerapproval data. The merchant device may then be configured to add the tipamount to payment amount to generate the total amount, which may be acomponent and/or a separate part of the secured payment approval data.

At 1516, the merchant device may be configured to send the securedpayment approval data to the central system. In some embodiments, thesecured payment approval data may be sent to the central system withoutany substantial processing and/or decoding by the merchant device. Assuch, the central system may be configured to facilitate financialtransactions between the consumer device and merchant device (e.g.,process payments from the consumer payment account to the merchant).

In some embodiments, the merchant device may be configured to store thesecured payment approval data for a period of time prior to sending thesecured payment approval data to the central system. For example, if thesecure connection with the central system is lost or otherwiseunavailable, the secured payment approval data may be stored until thesecure connection is reestablished.

At 1518, the central system may be configured to validate the securedpayment approval data and when the secured payment approval data isvalidated, process the payment. As discussed above, in some embodiments,the secured payment approval data may include the consumer approval data(e.g., as generated by the consumer device using the transaction dataand the private key) and the transaction data. As such, the centralsystem may be configured to generate or otherwise recreate the consumerapproval data using the transaction data and the private key stored atthe central system. If the recreated consumer approval data matches whatwas sent with the secured payment approval data from the merchantdevice, the secured payment approval data may be validated. As discussedabove, the private key may be configured to validate the secured paymentapproval data such that the data may be relied upon and therebyprocessed or otherwise used.

Where encryption was used to secure the payment approval data with thewallet identifying data, the central system may be configured to decryptthe payment approval data with the corresponding private key.

In some embodiments, processing the payment may further includecommunicating with one or more payment processing servers, third partyservers, credit card servers, bank account servers, and/or any othertype of financial transaction server that may be suitable to completethe financial transaction. For example, the central system may sendtransaction data to one or more third party servers and receive anindication as to whether the financial transaction was successful.

At 1520, the central system may be configured to send a paymentconfirmation to the merchant device. For example, the paymentconfirmation may indicate whether the payment was successfullyprocessed. An indication may be shown on the merchant device to alertthe merchant. For example, if the payment was not successful, themerchant may request that the consumer provide an alternate form ofpayment and/or to resubmit the payment via the consumer device.

At 1522, the central system may be configured to send a receipt for thepayment to the merchant device, which may then be sent to the consumerdevice at 1524 via the PAN connection. As such, the consumer device doesnot need an active connection to the central system to receive thereceipt. The receipt may alternatively, and/or additionally, be sentdirectly to the consumer device, such as when a direct connection to theconsumer device is available.

In some embodiments, two or more consumers (e.g., via consumeridentifying data) may be associated with the same unit of location(e.g., dine-in location) and/or restaurant tab. For example, theconsumers may be members of the same party and seated accordingly at acommon table. Method 1500 may be modified to allow consumers to settle(e.g., split) the restaurant tab (e.g., accordingly to consumerspecifications).

For example, the merchant device may be configured to send transactiondata (e.g., including the payment amount) to two or more consumerdevices associated with the same table identifier and/or restaurant tabidentifier at 1508. Alternatively and/or additionally, a consumer devicemay be configured to share the transaction data received from themerchant device with other consumer devices (e.g., either using directconnections or via the merchant device over the PAN network). The two ormore consumer device may be each configured to pay a portion of thetotal payment amount. In some embodiments, the transaction data mayfurther include menu item data. Here, each consumer device may beallowed to select one or more menu items in the restaurant tab asindicated by the transaction data. A total cost for each consumer devicemay be determined by the consumer devices. Next, payments using themultiple consumer devices may be processed based on the techniquesdescribed herein. Additional examples of payment splitting amongconsumer devices, applicable to some embodiments, are discussed in U.S.Provisional Patent Application No. 61/706,664, entitled “Online Orderingfor In-Shop Service,” incorporated by reference above.

FIG. 22 shows an example receipt display 2200, in accordance with someembodiments. Receipt display 2200 may be shown on the consumer device toprovide an indication to the consumer that the financial transaction wassuccessfully. As such, receipt display 2200 may include transaction dataat 2202 and payment confirmation display 2204, confirming payment viathe consumer device.

FIG. 23 shows a receipt notification display 2300 that may beadditionally and/or alternatively shown on the consumer device. Forexample, receipt notification display 2300 may be popup notificationthat may be presented on the consumer device, even when the consumerdevice is locked or executing the consumer service in the background.Receipt notification display 2300 may include notification selection2302 that includes transaction price indicator 2304 and merchantindicator 2306. In some embodiments, displays providing more detailedreceipt information may be shown on the consumer device responsive tothe consumer selecting notification selection 2302.

FIG. 24 shows an example receipt listing display 2400, in accordancewith some embodiments. Receipt listing display 2400 may be configured toprovide a listing of receipts associated with the consumer paymentaccount. Receipt listing display 2400 may be accessed, for example, byselecting receipts selection 1906 in consumer service menu display 1900.As shown, a listed receipt (e.g., listed receipt 2402) may include adisplay of merchant image 2404 (e.g., a trademark, symbol, slogan, icon,graphic, photograph, etc.), merchant name 2406, transaction date 2408and/or amount paid 2410. The receipts may be listed based on virtuallyany ordering criteria, such as the transaction date or merchant name, insome example embodiments.

In some embodiments, receipts may be searchable. For example, a consumermay enter search criteria (e.g., merchant name or transaction date asshown in FIG. 2400) in receipt search 2412. Responsive to entering thesearch, the consumer device may show a listing of receipts that fit, orcome closest to fitting, the search criteria.

In some embodiments, the listed receipts in receipt listing display 2400may be selectable. Upon selecting a listed receipt, additionalinformation about the receipt may be shown on the consumer device. Forexample, upon selecting listed receipt 2402, the consumer device may beconfigured to show receipt display 2500. The discussion above regardingreceipt display 2200 may be applicable to receipt display 2500. In someembodiments, receipt display 2500 may alternatively and/or additionallyinclude payment source identifier 2502. As shown in FIG. 25, paymentsource identifier 2502 indicates that the payment was made with a creditcard account having a credit card number ending with 2345 and a 12/15expiration date.

In some embodiments, the consumer device may be configured to allow theconsumer to view items associated with the receipt. For example, theconsumer may select receipt item selection 2504 in receipt display 2500.FIG. 26 shows an example view receipt items display 2600 that includesreceipt items listing 2602. As shown, receipt items listing 2602 mayinclude a list of items and associated price data.

Returning to FIG. 15, at 1526, the merchant device may be configured tosend consumer information to the central system. For example, theconsumer information may include menu item data indicating the one ormore menu items that were associated with the restaurant tab at 1504. Insome embodiments, the consumer information may include dine-in locationpreference data (e.g., as received from the consumer device at 1322 ofmethod 1300) and/or the dine-in location as determined based on locationdata (e.g., at 1336 of method 1330). The consumer information, dine-inlocation preference data, and or any other suitable type of informationmay be sent to the central system to facilitate consumer service, suchas upon a subsequent visit to the restaurant by the consumer. Forexample, the central system may be configured to store, process and/orsend the consumer information back to a merchant device (e.g., at 1320of method 1300). Method 1500 may then end.

Exemplary System Architecture

FIG. 27 shows system 2700 including an example network architecture,which may include one or more devices and sub-systems that areconfigured to implement some embodiments discussed herein. For example,system 2700 may include central system 2702, which can include, forexample, central server 2704 and central database 2706, among otherthings (not shown). Central server 2704 may be any suitable networkserver, a plurality of networked servers, and/or other type ofprocessing device. Central database 2706 may be any suitable networkdatabase configured to store information that may be used to facilitatethe techniques as discussed herein. In this regard, system 2702 mayinclude, for example, at least one backend data server, networkdatabase, cloud computing device, among other things.

Central system 2702 may be coupled to one or more merchant devices(e.g., merchant device 2710) via network 2708. In this regard, network2708 may include any wired or wireless communication network including,for example, a wired or wireless local area network (LAN), personal areanetwork (PAN), metropolitan area network (MAN), wide area network (WAN),mobile broadband network, or the like, as well as any hardware, softwareand/or firmware required to implement it (such as, e.g., networkrouters, etc.). For example, network 2708 may include a cellulartelephone, an 802.11, 802.16, 802.20, and/or WiMax network. Further, thenetwork 2708 may include a public network, such as the Internet, aprivate network, such as an intranet, or combinations thereof, and mayutilize a variety of networking protocols now available or laterdeveloped including, but not limited to TCP/IP based networkingprotocols.

As discussed above, merchant device 2710 may be associated with amerchant, such as a retail store, restaurant, etc. or one or moreemployees of the merchant. In some embodiments, merchant device 2710 maybe a POS device that is configured to receive payments at the merchant'sshop. As such, merchant device 2710 may include a personal computerand/or other networked device, such as a cellular phone, tabletcomputer, mobile device, etc., that may be used for any suitable purposein addition to providing POS functionality at the restaurant.

System 2700 may further include one or more consumer devices (e.g.,consumer device 2712). Consumer device 2712 may connect with merchantdevice 2710 via network 2708 and/or PAN network 2716. As such, consumerdevice 2712 may be configured to make communicate with merchant device2710 via PAN network 2716 even if consumer device 2712 and/or merchantdevice 2710 do not have active connections with network 2708.

In some embodiments, central system 2700 may further include one or morethird party systems (e.g., third party system 2714), among other things.In some embodiments, different third party systems may be associatedwith different types of payment sources or payment destinations. Thusfor each payment source or destination, data may be sent to anappropriate third party system (e.g., a credit card transaction server,a bank account, etc.) to validate and/or process payments. Furthermore,employee accounts, merchant accounts, and/or consumer payment accountsmay be associated with one or more third party accounts that areprovided by third party system 2714.

In some embodiments, central system 2702 may be a multi-tenant databasesystem configured to provide services to a plurality of consumers andmerchants. Additionally and/or alternatively, central system 2702 may beconfigured to include, or work in connection with, online orderingsystems (e.g., shop online and pickup), promotional systems (e.g., dealvoucher accounts, offerings, purchases, and redemptions, where the valueof a redeemed voucher may be deducted from the payment), merchantsystems (e.g., kitchen systems for restaurants), and/or appointmentsystems (e.g., scheduling a reservation at a restaurant). As such, thetechniques disclosed herein may be applicable to any environment thatinvolves consumer and merchants.

FIG. 28 shows a schematic block diagram of circuitry 2800, some or allof which may be included in, for example, central system 2804, consumerdevice 2812, and/or merchant device 2810. In accordance with someexample embodiments, circuitry 2800 may include various means, such asone or more processors 2802, memories 2804, communications modules 2806,and/or input/output modules 2808.

In some embodiments, such as when circuitry 2800 is included in merchantdevice 2810 and/or central system 2802, payment/redemption module 2810may also or instead be included. As referred to herein, “module”includes hardware, software and/or firmware configured to perform one ormore particular functions. In this regard, the means of circuitry 2800as described herein may be embodied as, for example, circuitry, hardwareelements (e.g., a suitably programmed processor, combinational logiccircuit, and/or the like), a computer program product comprisingcomputer-readable program instructions stored on a non-transitorycomputer-readable medium (e.g., memory 2804) that is executable by asuitably configured processing device (e.g., processor 2802), or somecombination thereof.

Processor 2802 may, for example, be embodied as various means includingone or more microprocessors with accompanying digital signalprocessor(s), one or more processor(s) without an accompanying digitalsignal processor, one or more coprocessors, one or more multi-coreprocessors, one or more controllers, processing circuitry, one or morecomputers, various other processing elements including integratedcircuits such as, for example, an ASIC (application specific integratedcircuit) or FPGA (field programmable gate array), or some combinationthereof. Accordingly, although illustrated in FIG. 28 as a singleprocessor, in some embodiments, processor 2802 comprises a plurality ofprocessors. The plurality of processors may be embodied on a singlecomputing device or may be distributed across a plurality of computingdevices collectively configured to function as circuitry 2800. Theplurality of processors may be in operative communication with eachother and may be collectively configured to perform one or morefunctionalities of circuitry 2800 as described herein. In an exampleembodiment, processor 2802 is configured to execute instructions storedin memory 2804 or otherwise accessible to processor 2802. Theseinstructions, when executed by processor 2802, may cause circuitry 2800to perform one or more of the functionalities of circuitry 2800 asdescribed herein.

Whether configured by hardware, firmware/software methods, or by acombination thereof, processor 2802 may comprise an entity capable ofperforming operations according to embodiments of the present inventionwhile configured accordingly. Thus, for example, when processor 2802 isembodied as an ASIC, FPGA or the like, processor 2802 may comprisespecifically configured hardware for conducting one or more operationsdescribed herein. As another example, when processor 2802 is embodied asan executor of instructions, such as may be stored in memory 2804, theinstructions may specifically configure processor 2802 to perform one ormore algorithms and operations described herein.

Memory 2804 may comprise, for example, volatile memory, non-volatilememory, or some combination thereof. Although illustrated in FIG. 28 asa single memory, memory 2804 may comprise a plurality of memorycomponents. The plurality of memory components may be embodied on asingle computing device or distributed across a plurality of computingdevices. In various embodiments, memory 2804 may comprise, for example,a hard disk, random access memory, cache memory, flash memory, a compactdisc read only memory (CD-ROM), digital versatile disc read only memory(DVD-ROM), an optical disc, circuitry configured to store information,or some combination thereof. Memory 2804 may be configured to storeinformation, data, applications, instructions, or the like for enablingcircuitry 2800 to carry out various functions in accordance with exampleembodiments discussed herein. For example, in at least some embodiments,memory 2804 is configured to buffer input data for processing byprocessor 2802. Additionally or alternatively, in at least someembodiments, memory 2804 may be configured to store program instructionsfor execution by processor 2802. Memory 2804 may store information inthe form of static and/or dynamic information. This stored informationmay be stored and/or used by circuitry 2800 during the course ofperforming its functionalities.

Communications module 2806 may be embodied as any device or meansembodied in circuitry, hardware, a computer program product comprisingcomputer readable program instructions stored on a computer readablemedium (e.g., memory 2804) and executed by a processing device (e.g.,processor 2802), or a combination thereof that is configured to receiveand/or transmit data from/to another device, such as, for example, asecond circuitry 2800 and/or the like. In some embodiments,communications module 2806 (like other components discussed herein) canbe at least partially embodied as or otherwise controlled by processor2802. In this regard, communications module 2806 may be in communicationwith processor 2802, such as via a bus. Communications module 2806 mayinclude, for example, an antenna, a transmitter, a receiver, atransceiver, network interface card and/or supporting hardware and/orfirmware/software for enabling communications with another computingdevice. Communications module 2806 may be configured to receive and/ortransmit any data that may be stored by memory 2804 using any protocolthat may be used for communications between computing devices.Communications module 2806 may additionally or alternatively be incommunication with the memory 2804, input/output module 2808 and/or anyother component of circuitry 2800, such as via a bus.

Input/output module 2808 may be in communication with processor 2802 toreceive an indication of a user input and/or to provide an audible,visual, mechanical, or other output to a user. Some example visualoutputs that may be provided to a user by circuitry 2800 are discussedin connection with the displays described above. As such, input/outputmodule 2808 may include support, for example, for a keyboard, a mouse, ajoystick, a display, an image capturing device, a touch screen display,a microphone, a speaker, a RFID reader, barcode reader, biometricscanner, and/or other input/output mechanisms. In embodiments whereincircuitry 2800 is embodied as a server or database, aspects ofinput/output module 2808 may be reduced as compared to embodiments wherecircuitry 2800 is implemented as an end-user machine (e.g., consumerdevice and/or merchant device) or other type of device designed forcomplex user interactions. In some embodiments (like other componentsdiscussed herein), input/output module 2808 may even be eliminated fromcircuitry 2800. Alternatively, such as in embodiments wherein circuitry2800 is embodied as a server or database, at least some aspects ofinput/output module 2808 may be embodied on an apparatus used by a userthat is in communication with circuitry 2800, such as for example,merchant device 2810 and/or consumer device 2812. Input/output module2808 may be in communication with memory 2804, communications module2806, and/or any other component(s), such as via a bus. Although morethan one input/output module and/or other component can be included incircuitry 2800, only one is shown in FIG. 28 to avoid overcomplicatingthe drawing (like the other components discussed herein).

Payment/redemption module 2810 may also or instead be included andconfigured to perform the functionality discussed herein related tofacilitating payment transactions discussed above. In some embodiments,some or all of the functionality facilitating payment transactions maybe performed by processor 2802. In this regard, the example processesand algorithms discussed herein can be performed by at least oneprocessor 2802 and/or payment/redemption module 2810. For example,non-transitory computer readable storage media can be configured tostore firmware, one or more application programs, and/or other software,which include instructions and other computer-readable program codeportions that can be executed to control processors of the components ofsystem 2800 to implement various operations, including the examplesshown above. As such, a series of computer-readable program codeportions may be embodied in one or more computer program products andcan be used, with a computing device, server, and/or other programmableapparatus, to produce the machine-implemented processes discussedherein.

Any such computer program instructions and/or other type of code may beloaded onto a computer, processor or other programmable apparatus'scircuitry to produce a machine, such that the computer, processor otherprogrammable circuitry that executes the code may be the means forimplementing various functions, including those described herein.

It is also noted that all or some of the information presented by theexample displays discussed herein can be based on data that is received,generated and/or maintained by one or more components of system 2700. Insome embodiments, one or more external systems (such as a remote cloudcomputing and/or data storage system) may also be leveraged to provideat least some of the functionality discussed herein.

As described above and as will be appreciated based on this disclosure,embodiments of the present invention may be configured as methods,mobile devices, backend network devices, and the like. Accordingly,embodiments may comprise various means including entirely of hardware orany combination of software and hardware. Furthermore, embodiments maytake the form of a computer program product on at least onenon-transitory computer-readable storage medium having computer-readableprogram instructions (e.g., computer software) embodied in the storagemedium. Any suitable computer-readable storage medium may be utilizedincluding non-transitory hard disks, CD-ROMs, flash memory, opticalstorage devices, or magnetic storage devices.

Embodiments of the present invention have been described above withreference to block diagrams and flowchart illustrations of methods,apparatuses, systems and computer program products. Each block of thecircuit diagrams and process flowcharts, and combinations of blocks inthe circuit diagrams and process flowcharts, respectively, can beimplemented by various means including computer program instructions.These computer program instructions may be loaded onto a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus, such as processor 2802 and/or payment/redemptionmodule 2810 discussed above with reference to FIG. 28, to produce amachine, such that the computer program product includes theinstructions which execute on the computer or other programmable dataprocessing apparatus create a means for implementing the functionsspecified in the flowchart block or blocks.

These computer program instructions may also be stored in acomputer-readable storage medium (e.g., memory 2804) that can direct acomputer or other programmable data processing apparatus to function ina particular manner, such that the instructions stored in thecomputer-readable storage medium produce an article of manufactureincluding computer-readable instructions for implementing the functiondiscussed herein. The computer program instructions may also be loadedonto a computer or other programmable data processing apparatus to causea series of operational steps to be performed on the computer or otherprogrammable apparatus to produce a computer-implemented process suchthat the instructions that execute on the computer or other programmableapparatus provide steps for implementing the functions discussed herein.

Accordingly, the block diagrams and flowchart illustrations supportcombinations of means for performing the specified functions,combinations of steps for performing the specified functions and programinstruction means for performing the specified functions. It will alsobe understood that each block/step of the circuit diagrams and processflowcharts, and combinations of blocks/steps in the circuit diagrams andprocess flowcharts, can be implemented by special purpose hardware-basedcomputer systems that perform the specified functions or steps, orcombinations of special purpose hardware and computer instructions.

CONCLUSION

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseembodiments of the invention pertain having the benefit of the teachingspresented in the foregoing descriptions and the associated drawings. Forexample, although the examples discussed herein do not require theconsumer to present a form of payment (such as a credit card) to themerchant, some embodiments of the merchant device can be configured towork with one or more peripheral devices that can receive paymentinformation directly from a consumer (such as a credit card reader,radio frequency identification reader, etc.) in addition to or insteadof from the central system. Furthermore, as discussed above, someembodiments may be configured to function in settings other thanrestaurants. For example, the dine-in location at a restaurant discussedherein may also refer to some other unit of location, such as a kiosk,aisle, information desk, display, counter or the like at a retail store.As such, the consumer may be associated with the unit of location andmay be provided assistance accordingly. Therefore, it is to beunderstood that the embodiments of the invention are not to be limitedto the specific embodiments disclosed and that modifications and otherembodiments are intended to be included within the scope of the appendedclaims. Although specific terms are employed herein, they are used in ageneric and descriptive sense only and not for purposes of limitation.

That which is claimed:
 1. A merchant device comprising: a displayconfigured to present interactive displays; communications circuitryconfigured to facilitate communications with a consumer device and acentral system, the communication circuitry being configured toestablish a wireless connection with a plurality of consumer devices toreceive wallet identifying data, the communications circuitry furtherconfigured to establish a separate connection with a central system toexchange the wallet identifying data received from the consumer devicewith consumer identifying data associated with the wallet identifyingdata; processing circuitry configured to: determine location dataindicating a location of the consumer device; determine a unit oflocation of a plurality of units of location at a merchant shop, theunit of location determined based on the location data and as thenearest unit of location to the consumer device of the plurality ofunits of location; and associate the consumer identifying data with theunit of location; and an output module configured to provide a userinterface to the display, the user interface comprising a graphicalrepresentation of a floor plan including at least some of the consumeridentifying data and the unit of location within the floor plan.
 2. Themerchant device of claim 1, wherein the circuitry configured todetermine the location data indicating the location of the consumerdevice includes the circuitry being configured to determine the locationdata based on a wireless communication received from the consumerdevice.
 3. The merchant device of claim 1, wherein the circuitryconfigured to determine the location data indicating the location of theconsumer device includes the circuitry being configured to: associate alocation device with each of the plurality of units of location, whereineach location device is associated with a unit of location at which thelocation device is located at the merchant shop; receive an signal froma location device indicating that the location device has received awireless communication from the consumer device; determine the unit oflocation based on the signal.
 4. The merchant device of claim 3, whereinthe circuitry is further configured to associate the merchant devicewith a unit of location where the merchant device is located, themerchant device being a second location device of the location devices.5. The merchant device of claim 4, wherein: the circuitry configured todetermine the location data includes the circuitry being configured todetermine the location data based on receiving signals from a pluralityof the location devices; and the circuitry configured to determine theunit of location includes the circuitry being configured to apply one ormore of near field communication (NFC), received signal strengthindication (RSSI), triangulation, and radio frequency identification(RFID) to the received indications from the plurality of locationdevices.
 6. The merchant device of claim 1, wherein the circuitryconfigured to determine the location data indicating the location of theconsumer device includes the circuitry being configured to: associate alocation device with each of the plurality of units of location, whereineach location device is associated with a unit of location at which thelocation device is located at the merchant shop. receive a signal from alocation device indicating that the location device has received a codefrom the consumer device; determine the unit of location based on thesignal.
 7. The merchant device of claim 6, wherein the code is opticallycaptured by the location device from a presentation of the code on adisplay of the consumer device.
 8. The merchant device of claim 1,wherein: the processing circuitry is further configured to receive, fromthe central system, consumer information; and the output module isconfigured to provide the user interface to the display including atleast some of the consumer information with the unit of location withinthe floor plain, wherein the consumer information includes at least oneof: dine-in preference data configured to facilitate customized diningservice; menu item preference data; consumer history data; purchasehistory data; promotion data indicating promotional vouchers availablefor purchase; promotion data indicating redeemable promotional vouchers;recommended menu item data; and table setting preference data.
 9. Themerchant device of claim 1, wherein the at least some of the consumeridentifying data includes one or more of a consumer name and a consumerimage.
 10. The merchant device of claim 1, wherein: the circuitry isfurther configured to receive, from the consumer device, consumerrequest data indicating a request for merchant assistance; and theoutput module is further configured to provide an indication of therequest to the user interface, the indication of the request associatedwith the unit of location within the floor plan.
 11. The merchant deviceof claim 1, wherein the user interface includes a selectable buttonassociated with the unit of location within the floor plan; and theprocessing circuitry is further configured to: generate a tab associatedwith the unit of location; in response to receiving input dataindicating selection of the selectable button, provide a tab display tothe user interface including selectable menu item buttons; and associatea menu item selected via a selectable menu item button with the tabassociated with the unit of location.
 12. The merchant device of claim1, wherein: the unit of location comprises a table identifier and theplurality of units of location comprise a plurality of tableidentifiers; and the processing circuitry configured to determine theunit of location includes the processing circuitry being configured todetermine the table identifier from the plurality of table identifiers,the table identifier associated with a table that is nearest to theconsumer device.
 14. A machine-implemented method of registeringconsumer device presence at monitored locations, comprising: wirelesslyreceiving, by circuitry of a merchant device, wallet identifying datafrom a consumer device; transmitting, by the circuitry, the walletidentifying data to a central system; receiving, from the central systemand by the circuitry, consumer identifying data associated with thewallet identifying data transmitted to the central system; determining,by the circuitry, location data indicating a location of the consumerdevice; determining, by the circuitry, a unit of location of a pluralityof units of location at a merchant shop, the unit of location determinedbased on the location data and as the nearest unit of location to theconsumer device of the plurality of units of location; associating, bythe circuitry, the consumer identifying data with the unit of location;and providing, by the circuitry, a user interface to the display, theuser interface comprising a graphical representation of a floor planincluding at least some of the consumer identifying data and the unit oflocation within the floor plan.
 15. The method of claim 14, whereindetermining the location data indicating the location of the consumerdevice includes determining the location data based on a wirelesscommunication received from the consumer device by the circuitry. 16.The method of claim 14, wherein determining the location data indicatingthe location of the consumer device includes, by the circuitry:associating a location device with each of the plurality of units oflocation, wherein each location device is associated with a unit oflocation at which the location device is located at the merchant shop;receive a signal from a location device indicating that the locationdevice has received a wireless communication from the consumer device;determine the unit of location based on the signal.
 17. The method ofclaim 16 further comprising, by the circuitry, associating the merchantdevice with a unit of location where the merchant device is located, themerchant device being a second location device of the location devices.18. The method of claim 17, wherein: determining the location dataincludes determining the location data based on receiving signals from aplurality of the location devices; and determining the unit of locationincludes applying one or more of received signal strength indication(RSSI) and signal triangulation to the received signals from theplurality of location devices.
 19. The method of claim 14, whereindetermining the location data indicating the location of the consumerdevice includes: associating a location device with each of theplurality of units of location, wherein each location device isassociated with a unit of location at which the location device islocated at the merchant shop. receiving a signal from a location deviceindicating that the location device has received a code from theconsumer device; and determining the unit of location based on thesignal.
 20. The method of claim 19, wherein the code is opticallycaptured by the location device from a presentation of the code on adisplay of the consumer device.
 21. The method of claim 14 furthercomprising, by the circuitry: receiving, from the central system,consumer information; and providing the user interface to the displayincluding at least some of the consumer information with the unit oflocation within the floor plain, wherein the consumer informationincludes at least one of: dine-in preference data configured tofacilitate customized dining service; menu item preference data;consumer history data; purchase history data; promotion data indicatingpromotional vouchers available for purchase; promotion data indicatingredeemable promotional vouchers; recommended menu item data; and tablesetting preference data.
 22. The method of claim 14, wherein the atleast some of the consumer identifying data includes one or more of aconsumer name and a consumer image.
 23. The method of claim 14 furthercomprising, by the circuitry: receiving, from the consumer device,consumer request data indicating a request for merchant assistance; andproviding an indication of the request to the user interface, theindication of the request associated with the unit of location withinthe floor plan.
 24. The method of claim 14, wherein the user interfaceincludes a selectable button associated with the unit of location withinthe floor plan; and the method further includes, by the circuitry:generating a tab associated with the unit of location; in response toreceiving input data indicating selection of the selectable button,providing a tab display to the user interface including selectable menuitem buttons; and associating a menu item selected via a selectable menuitem button with the tab associated with the unit of location.
 25. Themethod of claim 14, wherein: the unit of location comprises a tableidentifier and the plurality of units of location comprise a pluralityof table identifiers; and determining the unit of location includesdetermining the table identifier from the plurality of tableidentifiers, the table identifier associated with a table that isnearest to the consumer device.